Most traffic losses blamed on "the Google update" happened the week a site was rebuilt. The failure is nearly always mechanical, and nearly always avoidable.
Before the move
1. Record where you stand. Export your current pages and their traffic from Search Console, and crawl the current site so you have a full list of URLs, titles and descriptions. Without this list you cannot prove what broke.
2. Map old to new. Every existing URL needs a destination: the same page, a replacement, or a deliberate 404. A spreadsheet with two columns is enough. Do not leave this to a pattern rule and hope.
3. Keep the content. Redesigns often trim text "for cleanliness". Removed content removes the reason pages ranked. If a page ranks, keep its substance.
4. Check the staging site is blocked, and the live site is not. Staging should be behind a password, not only a noindex. And the moment you go live, the noindex and Disallow: / must be gone.
Launch day
- Put the redirects live with the new site, not after it.
- Crawl the new site immediately and look for 404s, redirect chains and missing titles.
- Check a sample of old URLs by hand, including ones with parameters and trailing slashes.
- Confirm the sitemap lists the new URLs, and submit it in Search Console.
- Check that analytics and Search Console still receive data: a missing tag hides everything that follows.
The first two weeks
- Watch Search Console coverage for a spike in "Not found" or "Excluded".
- Compare traffic per page against your pre-move export, rather than the site total. A site-level dip can hide one important page that vanished.
- Re-crawl weekly. Redirect chains appear as people fix things individually.
- Resist further changes. If you change five things while traffic moves, you learn nothing.
Changing domain
A domain change adds three steps: use permanent redirects for every URL, update the addresses in Search Console with the change-of-address tool, and ask the sites that link to you most to update their links. Redirects pass most of the value, but a direct link is better.
The most common mistakes
- Redirecting every old page to the homepage. Search engines treat those as soft 404s and the rankings go with them.
- Losing the sitemap during the move, so nothing points crawlers at the new structure.
- New pages that need JavaScript to show text, where the old ones were server-rendered.
- Canonical tags left pointing at the old domain.
- A
robots.txtcopied from staging withDisallow: /.
After it settles
Who owns which step
Migrations go wrong in the gaps between people. Agree these four owners before launch day, even if two of them are you:
- The URL map. One person owns the spreadsheet of old address to new address, and signs off that every row has a destination. Nobody edits the new site's structure after this is agreed without telling them.
- The redirects. One person implements the map, usually in the web server or CDN, and tests a sample by hand rather than trusting the rules.
- The content. One person confirms that pages which ranked kept their substance: the headings, the detail, the tables, the FAQs.
- The measurement. One person owns Search Console and analytics, and confirms data is still arriving an hour after launch.
Write the launch checklist as a list of yes-or-no checks, not as instructions. "Old product URLs return 301 to the new product page" is checkable. "Set up redirects" is not.
Rollback, decided in advance
Agree before launch what would make you roll back, and how. A useful threshold is a drop in indexed pages or a spike in 404s within 48 hours, not a wobble in daily traffic, which is normal for a week or two.
Keep the old site reachable somewhere private for a month. When something is missing, the fastest way to see what a page used to contain is to open it.
Once the site is stable, run a full audit and compare it with the crawl you saved before the move. Rankwell keeps every audit, so the score and issue counts sit side by side and the report tells you what changed since the previous run. Start one in site audit.