Free Website Audit: Discover what's holding your digital presence back
What should happen before launch?
Start with an inventory of the current site. Export or crawl indexable URLs, status codes, titles, descriptions, canonicals, headings, internal links, image references and important content. Add organic landing pages, conversions and backlinks when those sources are available. The inventory is the baseline for decisions, not a list to file away.
Write down what is changing. A migration may move a site to a new CMS, change the domain, redesign templates, alter information architecture, consolidate content or change hosting. Each change has a different SEO risk. A CMS move can alter URL output. A redesign can remove text and links. A domain move can affect trust and measurement. Naming the changes makes testing possible.
Konzept’s website migration service can be the implementation path when the site must be moved or rebuilt. The content and SEO migration checklist is a useful companion for a more granular task list.
How do you build the URL and redirect map?
Create one row for every important old URL. Record its status, organic role, target URL, redirect decision and test result. A page can redirect to an equivalent new page, remain at the same URL, be consolidated into a stronger page or be retired with a documented reason. Do not send every old page to the homepage. That hides the loss of relevance and makes debugging harder.
| Migration item | Before launch check | After launch check |
|---|---|---|
| URL inventory | Old URL list includes key pages, files and language paths | Sample old URLs return the intended permanent redirect or valid page |
| Redirects | One-to-one targets are reviewed; redirect chains are removed | Old URLs resolve in one useful hop and do not create loops |
| Metadata | Titles, descriptions and headings are mapped where content remains | Live templates expose the intended metadata and headings |
| Canonicals | Canonical rules match the new URL and language model | Canonical points to the preferred live URL, not staging or the old domain |
| Analytics | Measurement plan and annotations are ready | Sessions, conversions and key events are checked against the release |
| Crawl controls | Robots, noindex rules and XML sitemap plan are reviewed | Live rules allow intended pages and the sitemap contains valid URLs |
Keep the map in a shared document with an owner. Add notes for exceptions such as product pages, filters, PDFs, language alternates and URLs with external links. The goal is not to preserve every weak URL. The goal is to preserve useful intent and give every change a deliberate destination.
How should redirects be tested?
Test redirects on staging or a safe test environment before launch, then test the production response after the DNS or deployment change. Check protocol, hostname, trailing slash rules, uppercase paths, query strings, encoded characters and old file extensions. A redirect that works in a browser can still be wrong for a crawler or a script.
Prefer a direct permanent redirect from an old URL to its best matching new URL. Avoid a chain from old URL to an intermediate URL and then to the final page. Check for loops and accidental redirects from every page to one generic destination. Preserve query parameters only when the destination can use them safely; remove tracking parameters from canonical URL logic.
Use a sample that includes the highest-value pages, common templates and known edge cases. Then process the full URL map with a crawler or response check. Save the results. A migration without a test record is difficult to review when traffic changes later.
What should happen to analytics and tracking?
Record current measurement before the release. Note the property, data stream, conversion events, consent behaviour, campaign parameters, search-console verification and any server-side logs that support diagnosis. Prepare an annotation for the launch date and any planned downtime.
After launch, check that the new templates load the measurement code once, consent choices still work and key actions are recorded. Compare counts by page type and device where the data supports it. A change in tracking can look like a change in traffic. Do not call a ranking problem until collection and reporting have been checked.
Review internal links, canonical URLs and XML sitemap entries with the same care. Search engines need crawlable links to discover the new structure. The SEO and AEO service can cover technical search work after the migration when the team needs continued review.
How do you prepare staging and launch QA?
Keep staging protected from indexing. Test the pages that represent every important template: home, service, industry, article, project, category, search, contact and error pages. Check status codes, rendered text, metadata, structured data, links, forms, images, language paths, mobile layout and performance budgets agreed in the brief.
Do not treat a green visual review as SEO approval. A page can look correct while its canonical points to staging, a noindex directive remains active, internal links use old paths or its sitemap is empty. Add explicit SEO checks to the release checklist and record who approved each risk.
If the build includes a headless CMS, check how draft content, previews, pagination, media URLs and redirects are represented in the new system. If a client team owns content, show them how to create a page without changing the URL or removing required metadata. The migration is also a handover problem.
What should you monitor after launch?
Check the live site immediately. Confirm the homepage, critical templates, old URLs, redirects, robots.txt, XML sitemap, canonicals and analytics. Look for 4xx and 5xx responses, redirect spikes, missing titles, noindex pages and unexpected URL patterns. Compare the first period with the baseline, but do not expect every signal to settle at once.
Use search-console coverage and performance data when available. Review server logs for crawlers requesting old URLs or error paths. Watch organic landing pages, conversions and important branded or non-branded queries. A short drop can have several causes; a persistent pattern needs a focused diagnosis.
Make a recovery plan before the release. Define who owns the rollback decision, which change can be reversed, where the last stable build lives and how redirects or DNS records can be restored. Rollback is not always the best answer, especially when the new site has already changed external links, but the decision should not be invented during an incident.
What migration evidence can you review?
The public work portfolio contains CMS project records such as Infonet and 7D Group website. These names help a buyer see the types of digital work in the portfolio. They do not prove that a new migration will have the same scope, outcome or timeline. Ask for a mapping of your own URL set and systems.
The safest evidence is your own test record: URL count, redirect results, crawl errors, analytics checks, content decisions and post-launch observations. Use named project pages for context, not invented migration metrics or guarantees.
When should a migration audit be requested?
Request help before launch when the current site has valuable search pages, several languages, many templates, a new domain, a complex commerce catalogue or an uncertain redirect plan. A pre-launch review can find missing mappings while the old site is still available.
Request a post-launch audit when old URLs return errors, important pages disappear, analytics no longer records actions, search engines index the wrong URLs or organic landing pages change unexpectedly. The performance audit can be relevant when the migration also changed speed or technical delivery, but it does not replace URL and redirect QA.
Start with the smallest useful brief: current URL, target URL or platform, known constraints, launch date, content owner and the pages that matter most. Then request a quote or book a call with the migration map. A clear scope gives the team a way to test and recover instead of guessing after launch.
