A new site can be better looking, faster and easier to update, and at the same time lose half its organic traffic on launch day. It happens when the project focuses on design and features and nobody systematically compares what the old site was telling search engines with what the new one says. Unlike a domain change, here the address stays the same, and that is exactly why the risk gets underestimated.
The principle: compare, don't guess
The rule I follow is simple: crawl the old site before launch and the new site in staging, then compare the two crawls. Every difference must be explained. If an element changes, it must be a choice, not a side effect of the new template.
A desktop crawler lets you export both crawls to a spreadsheet and set them side by side, URL by URL.
What to compare
URLs
- Do the URLs stay identical? If the new CMS imposes a different structure, for example by adding
/category/or changing the extension, you need a complete redirect map. - Are trailing slashes and capitals handled as before?
- Do archive, tag and author pages still exist or do they vanish?
Status codes
- Do pages that returned 200 still do so?
- Do deleted pages have a redirect or an intentional 404/410?
Page elements
| Element | Question |
|---|---|
| Title | is it the same, or does the template add suffixes and truncate the text? |
| Meta description | was it migrated or does the CMS generate it empty? |
| H1-H2 headings | is the main content still marked up as a heading? |
| Canonical | does it point to the right URL, with the correct protocol and host? |
| Meta robots | no noindex left over from staging? |
| Hreflang | have the pairs between languages been recreated? |
| Structured data | are the same types present and valid? |
| Alternative text | do images still have their alt? |
Content
Redesigns tend to shorten text: "fewer words, more images". Sometimes that is an improvement, but if a page that ranked for a specific search loses the paragraphs that answered that search, the ranking goes with them. Compare word counts per page and look carefully at the biggest drops.
Also watch out for content moved into tabs, accordions or carousels loaded only on click: check that the text is present in the rendered HTML.
Internal links
Does the new menu have fewer items? Has the footer been simplified? Have the related links at the bottom of articles disappeared? Every internal link removed reduces the discoverability of the pages it pointed to. Compare the number of inbound links for each URL across the two crawls.
Performance
Measure the main pages in the lab before and after. A redesign heavy with fonts, animations and third-party scripts can clearly worsen load times, even on a theoretically more modern CMS.
Staging
The test environment must be:
- password protected or restricted by IP address, so it doesn't end up in the index;
- configured as closely as possible to production, with the same web server and the same redirect rules;
- populated with real content, not placeholder text.
The classic risk is the opposite one: staging's noindex or robots.txt block reaching production with the launch. Put this check at the top of the release-day list.
Launch day
- Check that robots.txt and meta robots are the production ones.
- Test the redirects against the list of historical URLs.
- Regenerate and submit the sitemap.
- Run a new crawl immediately and compare it with the old site's.
- Keep an eye on server logs for 404s and 5xx errors.
In the following weeks
- Monitor indexing and clicks by page group, not just the total.
- Compare the main queries: if some lose positions, look at what changed on those specific pages.
- Collect 404s from the logs and add the missing redirects.
A slight, temporary dip is normal while engines reprocess the pages. A sharp drop concentrated in one section almost always points to a specific technical problem, to be found by comparing the crawls.
In short
- Crawl the old site and staging, then compare every difference.
- Keep the URLs or prepare a complete redirect map.
- Check titles, canonicals, meta robots, hreflang, structured data and internal links.
- Protect staging with a password and make sure its blocks don't reach production.
- After launch, monitor by section and fix 404s from the logs.
