A website redesign doesn’t lose rankings because Google dislikes your new look. It loses them because the things Google had already crawled, indexed, and learned to trust — your URLs, page copy, headings, internal links, load speed — quietly change or disappear, and nobody tells Google where they went.
The good news: almost every one of those failures is preventable, and none of the prevention is exotic. Website redesign SEO comes down to four things — an inventory, a redirect map, rules about what the new pages must keep, and ninety days of attention afterward — and that’s how you preserve rankings after a redesign instead of rebuilding them.
This is the SEO migration checklist we use when we rebuild a site that already ranks: pre-launch work, launch day, and the post-launch monitoring that catches problems while they’re still cheap to fix.
Why Website Redesign SEO Goes Wrong (It’s Rarely the Design)
Rankings are attached to specific URLs with specific content, and a redesign touches both. Six ways it usually goes wrong:
1. URLs change and nothing redirects
Your old services page lived at /plumbing-services; the new one lives at /services/plumbing/. Without a redirect, the old URL returns a 404, every backlink (a link from another website) pointing at it now points at nothing, and Google has to find the new page from scratch. In our experience it’s the most common cause of post-redesign drops, and the easiest to prevent.
2. Content gets “cleaned up”
Designers like white space. Google liked the 600 words about foundation repair quietly ranking for a dozen long-tail queries. When those paragraphs become a tagline and three icons, the queries go with them.
3. Titles and headings get rewritten for style
“Fort Worth Roof Replacement” becomes “Let’s Talk About Your Roof.” It reads nicer — and removes the exact phrase people search for from the most important spots on the page.
4. Internal links vanish
Old sites accumulate links between pages — body copy, footers, sidebars. A slimmer nav with no footer links can cut the paths to a page from twenty to one, and Google uses those paths to judge which pages matter.
5. The new site is slower
A heavy theme or page builder often ships more JavaScript, CSS, and image weight than the site it replaced — bad for Core Web Vitals and for the people trying to call you.
6. Staging blocks ship to production
The noindex tag or password protection that kept the staging site (the private preview of the new build) out of Google gets copied to the live site — or a staging robots.txt block ships with it and stops Google crawling at all. It happens more than anyone admits.
Pre-Launch: Inventory Everything That Currently Ranks
Website redesign SEO starts before design does: you can’t preserve what you haven’t measured. Snapshot the site as it exists today — it takes an afternoon, and it’s the step that usually gets skipped.
| What to capture | Where to get it |
|---|---|
| Every live URL with its title tag, H1, meta description, and word count | A site crawler (Screaming Frog’s free tier crawls up to 500 URLs, enough for most small business sites) |
| Pages earning clicks and impressions, and their queries | Search Console (Google’s free reporting tool for site owners), Performance report, last 16 months — the maximum it keeps |
| Landing pages by traffic and conversions — some rank modestly but convert well | Your analytics |
| Pages with external backlinks | Search Console Links report, plus any backlink tool |
| Current Core Web Vitals — your baseline | Search Console Core Web Vitals report and PageSpeed Insights (if you’re too small for real-user data, record the lab scores) |
| Existing schema, canonical tags (the tag that names the “official” URL for a page), and redirects | Crawler export; your server or CMS redirect list |
Sort the list by clicks. The top pages — usually the homepage, core service pages, and a few blog posts — are untouchable: URLs stay, headings stay, copy can be improved but not gutted.
Say you run an HVAC company in Plano and /ac-repair-plano brings in a third of your organic leads. That page doesn’t get a new URL because the new navigation would be tidier. Tidy is not a ranking factor.
Build the 301 Redirect Map Before Design Is Finished
A 301 is a permanent redirect: a server response telling browsers and crawlers “this page has moved here, for good,” so Google consolidates ranking signals onto the new URL. A 302 is temporary and promises nothing. An instant meta-refresh or JavaScript redirect is treated as permanent but processed less reliably (JavaScript redirects only count once Google renders the page), so Google recommends server-side redirects. Use server-side 301s.
The 301 redirect map itself is a two-column spreadsheet: old URL, new URL. A few rules:
- One old URL to one new URL, matched by topic. The old AC repair page goes to the new AC repair page — not the services hub, not the homepage. Dump dozens of pages onto the homepage and Google may treat them as soft 404s (pages it decides are effectively “not found” whatever the server says), and those signals evaporate anyway.
- Keep the URL when you can. The cheapest redirect is the one you don’t need; if a URL works and ranks, carry it over unchanged.
- No chains. If an old redirect already sends
/services.htmlto/services, and that page is now moving to/services/, point the original straight at the final destination. - Handle the boring variants. Trailing slash or none, uppercase or lowercase,
httporhttps,wwwor bare domain. Pick one canonical form and redirect the rest. - Leave them in place. Google’s site-move guidance recommends keeping redirects for at least a year. Ours is simpler: never remove them.
If the domain itself is changing — say a Denton law firm rebrands from .net to .com — the map works the same way, plus Search Console’s Change of Address tool after launch. Google’s site migration documentation walks through that sequence.
Build the map while the new site structure is being planned, not the night before launch — that’s when you can still argue for keeping a URL.
Carry Over Titles, Headings, Content, and Internal Links
Redirects preserve the address, not what made the page rank. That part of website redesign SEO is on you: for every page in your untouchable tier, the new version should keep
- The title tag — or an improved one that still leads with the same primary phrase.
- The H1 and H2 structure. Reorder headings if you must; don’t strip the keywords out for the sake of a vibe.
- The body copy. Rewrite for clarity and cut what’s genuinely dead, but don’t drop below the substance that was ranking. If a page had 800 useful words, the redesign shouldn’t leave it with 90.
- Image alt text and file names. Easy to lose when images are re-exported from a design tool.
- Schema markup and canonical tags. Your LocalBusiness or Service schema markup should ship on the new pages, with the new URLs inside it.
Internal links deserve their own paragraph. Point every link in the new site — navigation, footer, body copy, buttons — directly at the new URLs rather than through redirects, and confirm your important pages are still linked from more than one place. If the old footer linked to all eight service pages and the new one links to none, that’s a signal loss you chose.
Before launch, crawl the staging site and lay the export beside your inventory: every untouchable URL present, title and H1 matching or deliberately improved, word count in the same range, no page reachable only from the sitemap. Anything that fails goes back to the designer, not to launch.
Our technical SEO checklist goes deeper on each of these, page by page.
Don’t Launch a Site Slower Than the One You Had
Speed is the part of website redesign SEO that’s easy to promise and easy to lose — the new site is often slower than the older, uglier one it replaces.
Google’s Core Web Vitals thresholds are the target: Largest Contentful Paint (how fast the main content appears) at or under 2.5 seconds, Interaction to Next Paint (how fast the page responds to a tap) at or under 200 milliseconds, and Cumulative Layout Shift (how much things jump around) at or under 0.1. Google judges these on real-user data at the 75th percentile, mobile and desktop separately, and staging only gives you lab numbers — so treat a green lab score as necessary, not sufficient, and confirm with field data after launch.
The practical checks before launch:
- Run PageSpeed Insights (mobile) on the same five key pages on the old site and on staging; record LCP, INP, and CLS side by side.
- Set an image budget: heroes under roughly 200 KB as WebP or AVIF, with explicit width and height so nothing shifts while loading.
- Cap web fonts at two families.
- Defer chat widgets and tracking scripts until the page has loaded.
It’s a large part of why we hand-code every site we build — no plugin layer to bloat, and every build targets green Core Web Vitals. We unpack the three metrics in Core Web Vitals explained.
Launch Day: Seven Checks Before You Walk Away
Launch is a checklist, not a moment. Work through it in order, with whoever built the redirect map on hand.
- Remove the staging blocks —
noindexmeta tags, anyX-Robots-Tag: noindexresponse header, password protection, and therobots.txtDisallow. Then view source on the live homepage and check its response headers. - Deploy the redirect map and test it. Run the full old-URL list through a crawler in list mode (paste the URLs in rather than crawling) and confirm every one returns a 301 to the intended destination — not a 302, not a 404, not a chain.
- Check canonical tags on a sample of pages. They should point to the live URL, not a staging domain.
- Submit the new XML sitemap in Search Console and remove the old one. It should contain only live, indexable URLs.
- Verify the property. If the domain changed, verify the new one in Search Console and run the Change of Address tool. If only paths changed, a Domain property still works; a URL-prefix property needs a new entry if
httpsorwwwchanged too. - Update everything that points at you: Google Business Profile website link, social profiles, directory listings, email signatures, and any ads aimed at old URLs.
- Test what makes money. Forms submit, phone numbers are tap-to-call, tracking fires, the chat widget loads. A redesign that ranks but doesn’t convert has failed quietly.
Launch on a weekday morning, so a problem gets a full workday instead of a Friday night.
Post-Launch: 90 Days of Search Console Monitoring
Website relaunch SEO doesn’t end at launch. Some fluctuation in the first few weeks is normal — Google is recrawling, processing redirects, and re-evaluating changed pages. A drop that keeps dropping is not, and Search Console monitoring is how you tell the difference.
- Pages (indexing) report: a spike in “Not found (404)” or redirect errors means URLs you missed in the map. Fix them in batches.
- Performance report: compare the 28 days after launch against the 28 before, by page. If a top page lost clicks, check its title, headings, content, and internal links against your snapshot.
- Core Web Vitals report: field data — measurements from real visitors — takes weeks to accumulate. If URLs slide from “good” to “needs improvement” once a full 28-day window of post-launch data is in, the new build has a real-world regression whatever the lab tests (PageSpeed Insights and the like) said. Check which metric moved.
- Crawl stats: a sustained rise in 404s or server errors means crawlers are still hitting URLs you didn’t handle.
Check weekly for the first month, then monthly through day 90. If a key page hasn’t recovered after two to three months and everything above checks out, the content changed more than you thought: compare old copy to new and put back what was working.
How We Build Redesigns SEO-First
A lot of redesigns treat SEO as a final pass — someone “checks it over” once the URLs are decided, the copy is cut, and the template is built. We flip the order.
The inventory and redirect map are built during the site-structure phase, ranking pages are flagged before copy is touched, and the site is hand-coded, crawled on staging, and speed-tested before it goes live. Launch day is the checklist above. If you keep us on for ongoing SEO services afterward, the Search Console watch continues and your monthly report tells you in plain English what moved.
You own the domain, content, and code, with no long-term contract. Our redesign process shows the sequence, and pricing is public.
Key takeaways
- Redesigns lose rankings through missing redirects, deleted content, rewritten headings, lost internal links, and slower pages — not because the design changed.
- Inventory every URL, its title and headings, and its Search Console traffic before design begins, and mark the top pages untouchable.
- Build a one-to-one 301 redirect map early, avoid chains and homepage catch-alls, and never remove it.
- Keep titles, headings, body copy, alt text, and schema on the pages that rank; rewrite for clarity, not for less.
- Update internal links to point directly at new URLs instead of relying on redirects, then crawl the staging site against your inventory before launch.
- Test the staging site against Core Web Vitals thresholds on a phone, confirm with real-user data after launch, and go live on a weekday morning.
- Watch Search Console for 404s, indexing errors, and per-page click changes — weekly for the first month, then monthly through day 90.
Frequently asked questions
A few weeks of fluctuation is normal — Google says a small-to-medium site takes a few weeks for most pages to move, and larger sites take longer. If redirects, content, and internal links were preserved, expect things to level out over the following two to three months; a drop that keeps worsening past that usually means something was lost. Growth beyond the old baseline follows the usual SEO timeline of three to six months before it compounds.
Only when there’s a real reason. Keep any URL that ranks or has backlinks; if you must change one, redirect it one-to-one with a 301 to the equivalent new page.
Every page with traffic, backlinks, or an equivalent on the new site — yes. Truly dead pages with no traffic and no links can return a 404 or a 410 (“gone for good”), and that’s fine.
Not by itself. Google ranks pages, not platforms. What matters is preserving URLs, content, and speed — and a leaner build usually improves the third.
Yes. Keep it live until the new site is fully tested on a staging domain that’s blocked from indexing, then swap the sites and deploy redirects at the same moment. Never leave both sites indexable at once.
Planning a redesign? Protect what already ranks.
Tell us what your current site ranks for and what you want the new one to do. We’ll talk through how the migration should work before anyone touches a design — reach out or email hello@anthroweb.com.