A redesign does not have to cost you rankings, and when it does, the cause is rarely the new design. It is almost always one of three things: a URL that moved without a redirect, a canonical host the new site does not enforce, or structured data the old site had and the new one does not.
All three are checkable before launch, not diagnosed afterward. This is the checklist for that, written for the person actually doing the technical work on a redesign, whether that is custom development work or a rebuild on an existing platform.
Why rankings actually drop after a redesign
The common explanation is that search engines "reset" a site after a redesign. They do not. A page's ranking is tied to its URL, its content, and a set of signals search engines have accumulated about that specific address over time.
Change the URL without telling anyone where it went, and those signals have nowhere to attach. Serve the same content from two different hosts, and the signals split between them instead of adding up.
Remove structured data that told search engines what a page was, and they are back to inferring it from scratch.
None of that is punishment. It is signals failing to transfer, which is a different problem with a different fix: map the transfer before you launch, rather than hope it happens on its own.
Map every URL before you touch the design
Start with a full list of every URL the current site has that gets any traffic, any backlinks, or any ranking at all. For each one, there are only three honest outcomes on the new site, and the mistake most guides make is treating the choice as one decision instead of three.
| If the old URL is | Do this | Not this |
|---|---|---|
| Staying, content unchanged | Leave it exactly as is | Redirect it to itself out of habit |
| Moving to a new address, equivalent content | 301 redirect, straight to the final URL | 302 (temporary) or a redirect chain through an old URL |
| Merging into another page | 301 redirect to the page it merged into | Redirect to the homepage or a category page instead |
| Gone, with nothing equivalent on the new site | 410 (Gone), or 404 if you are not certain | 301 to an unrelated page to "catch" the traffic |
The fourth row is the one most checklists skip, and it is where the most damage happens. Google's own guidance on moving a site is direct about it: do not redirect many old URLs to one irrelevant destination such as the homepage, because that can be treated as a soft 404 rather than a real page.
If a page is genuinely gone, say so with a 410. A redirect that goes nowhere useful is worse than an honest 404.
Once every URL has a destination and a status code, test the redirects as a batch before launch if your setup allows it, and check for chains: an old URL that redirects to another old URL that finally redirects to the new one. Each hop in a chain is a place a crawler can give up, and a place a human on a slow connection notices the wait.
Pick one canonical host and make the server enforce it
Before anything else on the new site goes live, settle four questions that have nothing to do with content: www or not, http or https, a trailing slash or not, and which one is the real, single address for every page. Google's canonicalization guidance treats these as duplicate-content sources in their own right, separate from anything a redesign changes on the page itself.
The common failure is not skipping this. It is doing half of it: a canonical tag that declares the www version correct, while the server still serves both www and non-www as 200 without redirecting one to the other.
A canonical tag is a request. A server-side redirect is what actually enforces it, and search engines eventually notice when the two disagree.
- One protocol only. If https works, http should 301 to it, not serve a duplicate.
- One host only. Pick www or non-www and 301 the other to it, sitewide, not page by page.
- One trailing-slash convention. Whichever you choose, redirect the other form rather than letting both resolve.
- Confirm the canonical tag on every page matches the URL the server actually redirects everything else toward. A mismatch here is invisible in a browser and obvious to a crawler.
Structured data does not carry over on its own
If the old site had schema markup, an FAQ block, review stars, an organisation entity, anything Google was reading as structured data, none of it survives a rebuild automatically. A new theme or a new framework starts from nothing, and markup is easy to leave out of a launch checklist because nothing visibly breaks when it is missing.
Treat it as a line item, not an assumption. List what the old site had, confirm each type is rebuilt on the new one, and validate the result with a real structured data testing tool rather than trusting the theme handled it.
A missing FAQPage or Organization entity will not throw an error. It will just quietly not be there.
Update the links, not only the redirects
A redirect fixes an old URL. It does not fix a new site that still links internally to the old address, which is a more common oversight than it sounds, especially when content is migrated in bulk rather than rebuilt page by page.
Every internal link on the new site should point straight at the new URL, not at an old one that happens to redirect correctly. A link that relies on a redirect to work is one extra hop for a crawler and one more place a chain can start if a URL ever moves again later.
If the rebuild is happening on WordPress specifically, the redirect and plugin migration steps look a little different again, mainly around which plugin owns the redirect table and what happens to it if that plugin changes.
The two weeks after launch
The work does not end at go-live. This is the part most teams do once and stop watching, right when it matters most.
- Submit the new XML sitemap, and confirm it lists only the new, live URLs, not a mix of old and new.
- Remove the noindex meta tag that was almost certainly on the staging environment. This is the single most common launch-day mistake, and it is invisible until someone notices traffic has stopped.
- Watch Search Console's coverage and crawl-error reports daily for the first two weeks, not just after launch day.
- Spot-check a sample of redirects in an incognito window, including a few that are not on the obvious high-traffic pages.
- Expect some short-term ranking movement even when everything above is done correctly. A clean migration is not a guarantee of zero volatility, it is a guarantee that any volatility recovers rather than becoming permanent.
How long should the old redirects stay live?
Longer than most advice suggests. "A few months" is common and wrong.
Backlinks to old URLs can persist for years, and removing a redirect early turns a working link into a dead one. Keep 301s in place indefinitely unless there is a specific reason to retire one.
Will rankings dip at all, even done correctly?
Often, briefly. Search engines still have to recrawl and re-evaluate the new URLs, which takes time even when every signal transfers cleanly. The difference between a normal, temporary dip and a real problem is whether it recovers within a few weeks or keeps declining, which is exactly what the daily Search Console check above is for.
