The most common reason a website loses rankings after a redesign isn't worse design or content — it's redirects done wrong: a URL changes without a permanent redirect, internal links still point at the old URL, or a page that used to bring in traffic gets missed entirely. Below are concrete before/during/after steps, drawn from redirects and removals we've actually carried out on noise-and-signal.com.
Before: Audit and Plan
Step 1: Audit your current URLs and indexing status. Before redesigning, know which URLs are currently indexed and which are driving traffic, so you know what you're protecting. Export your current sitemap.xml and cross-check it against Search Console's Coverage report — in our own early launch window (GSC data range 2026-09-14 to 09-19), our sitemap listed 114 URLs while Google recognized only 51 pages. If a gap like that isn't understood before a redesign, it's easy to misread post-redesign numbers as "everything disappeared."
Step 2: Build an old-URL-to-new-URL map. Every page whose URL will change needs an explicit one-to-one mapping — don't rely on "the homepage is still there, that's good enough." If a page is being retired with no direct replacement, decide which existing page it should point to instead of letting it become a 404.
Step 3: Decide on the redirect method and implement it at the right level. Permanent URL changes need a permanent redirect (HTTP 301, or a framework-level equivalent) so search engines pass the old URL's ranking signal to the new one; 302/307 are for genuinely temporary situations only. In our own case, we configured redirect rules in next.config.ts that permanently (308) redirect the retired /opensource route and /insights/rag-vs-fine-tuning (including its variant URLs) to /insights, rather than letting them 404 or hoping visitors find the new content on their own.
During: Update Everything Together, Not Half-Way
Step 4: Sitemap.xml should carry only new URLs — remove the old ones. A sitemap still listing redirected or retired URLs keeps sending crawlers to confirm a page that no longer exists, wasting crawl budget. Swap in the updated sitemap at the same time the redesign goes live.
Step 5: Point every internal link at the new URL — don't lean on redirects to cover for it. Redirects preserve ranking signal, but if your own navigation, footer, and inter-article links still heavily point at old URLs, every click adds an extra redirect hop, and crawlers spend more of their budget following redirect chains instead of reaching content directly. Update internal links as part of the redesign, not as an afterthought.
Step 6: Keep hreflang and canonical tags consistent through the redesign — don't mix old and new codes. Our own 2026-09-16 audit caught exactly this kind of inconsistency: the in-page 0 tag used zh-Hant while the sitemap and HTTP Link header used zh-TW — three contradictory signals, which we later unified. A redesign is exactly when this kind of "old code next to new code" tends to creep in, so it's worth double-checking.
Step 7: Re-check locale auto-detection so it doesn't override your redesigned canonical page. Frameworks like next-intl default to a 307 redirect based on the Accept-Language header. Googlebot usually doesn't send it, but ChatGPT-User, some browser-based crawlers, and Lighthouse do — which can make your redesigned zh-TW canonical page effectively invisible to them. If the redesign touches your locale routing logic at all, retest this specifically.
Step 8: Update llms.txt/llms-full.txt to match the redesign — don't leave stale descriptions in place. If your site serves a summary file for AI crawlers, and the redesigned page structure or service lineup no longer matches what's in that file, AI engines are reading outdated information. Our own /llms.txt and /llms-full.txt have to be updated every time we add or remove content, so files like these belong on the redesign's update checklist, not just the pages themselves.
After: Monitor and Consolidate
Step 9: The moment the redesign is live, use Search Console's URL Inspection tool to request re-indexing for key pages one by one. You can also batch-submit to engines that support it (Bing, Yandex) via IndexNow, but remember Google explicitly does not support IndexNow — submitting there doesn't mean Google was notified. Our own batch-submission script has pushed 406 URLs cumulatively, and Bing Webmaster Tools confirmed 112 sitemap URLs with 0 errors and 0 warnings, submitted September 19, 2026 and crawled successfully the next day.
A note on secondary search engines: don't expect data right away. In our own early launch window, Bing Webmaster Tools showed 0 total clicks and 0 total impressions (a new site, still processing), even though the sitemap status was already healthy — "1 known sitemap, 112 URLs, 0 errors, 0 warnings," crawled successfully the day after submission. That tells you the sitemap is being read; performance data for a new site just takes time to appear. Don't read an empty click count as a sign that your redirects failed.
Step 10: Watch Search Console's Coverage report closely after launch for abnormal buildup. Pay particular attention to whether "crawled — currently not indexed" and "discovered — currently not indexed" counts spike after the redesign — in our own early launch window we had 30 pages indexed against 21 not indexed (3 "verification failed," 18 "discovered — not indexed"). If a gap like that keeps growing instead of shrinking after a redesign, it usually means a redirect or internal link wasn't wired correctly.
Step 11: Cross-check more than one analytics source before concluding you lost rankings. Search Console only measures Google organic search; actual visitor behavior needs a separate analytics tool, and when the two disagree, it usually means the traffic was never from organic search in the first place. We saw exactly this: Vercel Analytics (last 7 days, pulled September 22, 2026) showed our /cases page with 25 visitors while that page had 0 Google impressions; site-wide referrers that week included social sources such as l.threads.com alongside google.com — so that page's visitors weren't coming from Google organic search. After a redesign, watching only your GSC numbers can make a page look like it "lost rankings" when it was never a search-driven page to begin with.
Step 12: When several pages cover the same topic, consolidate them around one primary page instead of letting them compete. Redesigns often leave old and new content side by side; pick one page as the primary source and link the others to it, rather than optimizing each separately for the same keywords.
Step 13: Confirm new content is actually deployed, not just finished locally. This sounds obvious, but content being "written" and content being "live" are not the same checkpoint, and a redesign process should never assume one implies the other. We recommend adding an explicit final step: open the live production domain in a private/incognito window and confirm the change is actually there, rather than trusting a local build or preview environment.
One more thing worth flagging: these thirteen steps fix redirect and technical-signal problems — they don't by themselves raise your brand authority. In our own 2026-09-16 audit, technical foundation scored 86, but brand authority signal scored only 5. Those are two different problems: a redesign done right protects your rankings, but "nobody talks about your brand off-site" only improves through sustained content and off-site presence over time.
Next Steps
The real risk in a redesign isn't that users need to get used to a new look — it's that ranking signal quietly resets because a redirect wasn't done right, and you don't find out for weeks. If you're planning a redesign, treat these thirteen steps as a checklist to run through, and pair it with our pre-launch SEO/GEO checklist. To talk through how to plan redirects and monitoring for your own redesign, see our website services, or reach out via contact.