Short answer: rankings usually drop after a redesign because old URLs no longer redirect to their new equivalents, or because something on the new site blocks indexing, such as a leftover noindex tag or a robots.txt rule from staging. Some movement in the first weeks is normal. A steep drop on pages that used to bring traffic is a sign something is broken. Fix it by mapping every old URL to its closest new page with a single 301, then confirming the new pages can be indexed.
Why do rankings drop after a redesign?
A redesign often changes URLs, titles, headings and internal links all at once. Google has to recrawl and reprocess all of it. Google's documentation on site moves says that when URLs change, you should map each old URL to its new one with server-side redirects, and it describes redirects as a signal that a page has moved. Without them, the old URL returns a 404 and the ranking history attached to it has nowhere to go.
The usual causes, roughly in order of how often agencies run into them:
- Old URLs return 404 because nobody built a redirect map.
- Everything redirects to the homepage instead of the matching page.
- Redirect chains, such as old to staging to final, or http to https to a new path.
- Temporary 302 redirects used where 301 was meant.
- A noindex tag, an X-Robots-Tag header or a
Disallow: /rule copied over from the staging site. - Content, titles and internal links changed so much that the new page no longer matches what ranked.
How do I tell which cause it is?
Work from the cheapest check to the most involved one. Take your top 20 landing pages from the old site (from analytics or an export from before launch) and test each one.
| What you see | Likely cause | Fix |
|---|---|---|
| Old URL returns 404 | No redirect | Add a 301 to the closest new page |
| Old URL lands on the homepage | Blanket redirect | Redirect page to page |
| Old URL returns 302 | Wrong redirect type | Change to 301 |
| Two or more hops before the final page | Redirect chain | Point the old URL straight at the final one |
| New page returns 200 but is not indexed | noindex or robots block | Remove the block, request reindexing |
A quick command shows the redirect behaviour for one URL:
curl -sIL https://example.com/old-services-pageThe output lists each hop. You want one HTTP/2 301 with a location: header pointing at the new page, then a single HTTP/2 200. If you see 404, a 302, or three hops, that is your problem. The same output also shows any x-robots-tag: noindex header on the final response.
What are the exact fix steps?
- Build a redirect map: old URL in one column, closest new URL in the other. Use the pre-launch crawl or the old sitemap as your list.
- Implement each as a 301. On WordPress, use your redirect plugin, the server config, or
wp_redirect()with a 301 status in code. On Cloudflare, Bulk Redirects can handle large lists at the edge. - Remove chains. Every old URL should reach the final page in one hop.
- Check the new pages for indexing blocks. In WordPress, look at Settings, Reading, and make sure "Discourage search engines from indexing this site" is unticked. Then check the page source for a robots meta tag and the response headers for X-Robots-Tag. You can run the noindex checker on any URL to see all of this at once.
- Open robots.txt and confirm it does not still carry the staging rule.
- Submit the updated sitemap in Search Console and use URL Inspection on your most important pages to request indexing.
- Keep the redirects in place. Google's site move guidance recommends leaving them up for at least a year.
What does a real case look like?
A law firm site we checked after a rebuild had a noindex tag on every page. The designer had left staging settings on at launch. Redirects were fine, but nothing could be indexed, so no redirect map would have helped. Checking the blocks and the redirects separately is what finds this.
What do I tell the client?
Keep it short and factual. Tell them that a redesign changes URLs and Google needs time to process the change, that you have checked every old page for a proper redirect and for indexing blocks, and what you fixed. Give a window for recovery, such as checking Search Console again in two and four weeks, rather than promising a date. Do not blame the redesign itself. The loss comes from specific, fixable gaps, and showing the list of what you fixed is more convincing than reassurance.
How does quietwatch help with this?
quietwatch checks your client sites every day for noindex tags, robots.txt blocks, X-Robots-Tag headers, broken sitemaps and pages that stop returning a healthy status, so a leftover staging setting gets flagged the day it appears. See what quietwatch checks every day for the full list. The free tool above is the place to start: run your top landing pages through it today.