A website redesign loses Google rankings for mechanical reasons more often than for aesthetic ones. URLs change, the only paragraph that answered a query gets cut, a noindex tag rides along from staging, internal links disappear into a new menu, or the new canonicals point at the wrong host. The visual design and the preservation of rankings are both real work. They are different workstreams, and they belong on the same calendar.
This is a checklist for owners, marketers, and the studio doing the build. Run it before the new templates are treated as final, on launch day, and for the first month in Google Search Console. Ordinary fluctuation will still happen. Competitors publish, demand moves, and Google reassesses templates. The checklist is how you avoid handing Google a broken site on top of that.
If local map listings matter as much as the site, pair this with Local SEO for San Diego and Orange County Businesses. If the site you are replacing is a product marketing site, SEO and Growth for SaaS and Web Products covers the ongoing work after the migration is stable.
Do the URL map before the visual design locks the navigation
Information architecture and URLs are the same decision. If the new navigation merges two services that currently rank for different queries, you have already chosen a redirect strategy, whether anyone has written it down or not. Freeze a draft URL map early enough that design can follow it. A beautiful sitemap that appears the week of launch is how important pages get folded into the homepage.
Keep a URL when the page's job stays the same. A redesign is a weak reason to change a slug that already earns impressions. Change a URL when the page's job truly changed, and write the redirect in the same row.
Crawl inventory
Crawl the current site before anyone unplugs the old CMS. A desktop crawler, an export from your host, or both, plus the Pages report in Search Console, is enough for most company sites. You are building a spreadsheet that becomes the migration contract.
• URL, exactly as it is requested, including trailing slash and uppercase variants you know people use.
• HTTP status, so you already know which URLs are redirects or soft errors today.
• Indexability: meta robots, any X-Robots-Tag header, and the canonical.
• Title and H1.
• Whether the body has unique copy worth keeping, in a few words, not a novel.
• A count or a sample of internal links pointing at the URL.
• Clicks and impressions from Search Console for a recent quarter, if the property exists. Pages with impressions get a named owner. Pages with none can still matter for a task, and they can be redesigned with a lighter touch.
• A note when you know the URL has backlinks or is printed on something you cannot edit, such as a PDF, a partner site, or a Google Business Profile.
Export the body copy and the meta fields to a file you control before the old system is retired. “We can pull it from the backup” is how paragraphs disappear.
URL mapping
Every old URL that can receive a hit needs a decision: keep, redirect to one specific new URL, or retire on purpose with a real 404. One old URL maps to one new URL that serves the same intent. A dozen service pages collapsed onto the homepage is a ranking plan only in the sense that the homepage might hold. It will not hold the queries those pages earned.
Decide host and format once: https, www or not, and trailing slash or not. Every other variant redirects to the chosen form in a single hop. Parameter URLs, old campaign URLs, and mixed-case duplicates get an explicit row or a tested rule. Write the new title and H1 in the same sheet so content and mapping stay attached.
If two old pages must become one, pick the destination because it matches the surviving intent, and be ready for the merged page to carry both jobs in the copy. If one old page must become two, the old URL still needs a single primary destination. The second new page earns its way through internal links. You cannot 301 one URL to two places.
301 redirects
Use a server-side 301. A meta refresh, a JavaScript location change, and a click-here interstitial are poor substitutes for a request Google can follow in one step. Avoid chains. Old should land on new, not on an interim URL that then redirects again. Each extra hop is another place for the map to rot, and it slows the first request a visitor makes.
Test a sample before launch and again the hour you ship. Include the top URLs by impressions, a URL with a trailing slash and one without, a mixed-case path, an http URL, and the www and non-www hosts. The check is the status code and the final URL, not a browser that quietly follows three hops and shows a page. Keep the map in version control. You will add rows after launch when logs show hits you missed.
Leave the redirects up. A plan to delete them after a few months drops links you forgot were pointed at the old paths: partner sites, email signatures, PDFs, and the long tail of queries you did not export. Redirects are cheap. Rebuilding a lost URL from memory is not.
Content parity
For every URL with meaningful impressions, the new page should answer the same query with equal or better specificity. A shorter page is an improvement when it is clearer and the answer is still there. A shorter page that deleted the only section a searcher needed is a loss, even when the new layout looks calmer.
Keep resource and article URLs that get impressions, including ones that look visually plain next to the new marketing pages. Design them so they belong on the new site. Unpublishing them to “clean up” throws away the part of the site Google already understood. PDFs and other files linked from those pages should still resolve, or the links should move to a file that does.
Images deserve a pass on pages that show up in image results or that explain a product. Keep specific alt text. Keep a filename when you know it is the thing people search for. Decorative replacements are fine on pages that were never about the picture.
Resetting article dates to the redesign day is a content change, not a design change. Leave original published dates alone unless the article was genuinely revised, and say so in the page when you do revise it.
Titles and meta descriptions
Give each indexable URL one unique title. Put the specific subject at the front and the brand at the end if you include the brand. A redesign is a common moment when specific titles get replaced with a slogan. The slogan can live in the header. The title has to tell a searcher, and a colleague, which page this is.
Use one H1 that matches the page's job. It can differ from the title, and it should still be the same subject. Template mistakes—the same H1 on every service page, or an H1 that is only a logo—show up fast in the crawl you run on staging.
Treat the meta description as snippet copy. Write it so a person can tell what they will get if they click. It will not rescue a page whose title and body no longer match the query. Unique descriptions on your important templates matter more than a description on every tiny tag archive.
Internal links
Primary navigation and the footer should use ordinary links to the URLs you care about. A menu that only appears after a script runs, or that is a stack of buttons with no href, makes the important pages harder to discover. On a marketing site, a person and a crawler should both be able to reach the main services and the main articles in a couple of clicks from the homepage.
Update in-body links to the final URLs. Leaving them pointed at old paths works only as long as the redirect holds, and it keeps your own site dependent on the migration map. While you are in the articles, fix links that already 404ed before the redesign. A migration is a poor time to preserve old mistakes.
Pages that used to sit two clicks from home should stay easy to reach if they still have a job. A resources index, or a clear services index, helps visitors and gives crawlers a clean path. Orphan pages—in the sitemap, linked from nowhere—are how new URLs stay unvisited.
Structured data
Inventory the JSON-LD on the old site: Organization or LocalBusiness, Article, Breadcrumb, FAQ, Product, and anything a plugin added that nobody remembers. Re-implement what is still true. Delete what is not. FAQ markup for questions that no longer appear on the page is a mismatch, and mismatches are the kind of structured data worth removing.
On a local business site, the name, address, and phone in the markup should match the footer and the Google Business Profile. Schema URLs should be the production URLs, never the staging host. Validate a few templates on a URL you are willing to have fetched, or with a local check, before you templatize a mistake across hundreds of pages.
Article markup should keep the original publish date. Breadcrumb markup should match the links a person can click. If you are unsure whether a type is accurate, ship the page without that block. Missing markup is quieter than wrong markup.
Staging noindex pitfalls
A noindex directive belongs on staging. The failure mode is shipping it. Check three places, because teams turn one off and leave the others: a meta robots tag, an X-Robots-Tag HTTP header, and a robots.txt that disallows the whole site. Any of the three, copied into production, will do the damage. An environment flag that “worked on staging” is the usual carrier. Confirm the production environment actually says production.
Canonicals fail in the same move. A production page that canonicals to the staging host, or to a URL that immediately redirects, spends the launch pointing Google away from the page you just published. Staging canonicals should be the staging URL or absent. Production canonicals should be the final production URL, consistent with the slash and host rules in your map.
Password-protect staging as well. noindex is an indexing instruction. It is not an access control. A login wall that returns HTTP 200 with a thin form can still be fetched and, if someone links it, treated as a page. Do not link staging from production, do not list staging URLs in the sitemap, and do not leave staging credentials in a public ticket.
Before you announce the launch, view source on production for a homepage, a service page, and an article. You want the title, the H1, and the main copy in the HTML, and you want the absence of noindex. Then open robots.txt on the production host and read it.
Launch day checks
Put the redirects live at the same moment as the new site. A gap in either direction—new URLs with no redirects, or redirects to a site that is not up—creates a window of errors you will see in logs and, shortly, in Search Console.
• Spot-check the top URLs by impressions: one hop, 301 to a 200, correct final host, title, H1, canonical, and an indexable response.
• Submit a sitemap that lists final production URLs only. Remove the staging host and the retired URLs from that file.
• Confirm the custom 404 returns status 404. A “not found” template that returns 200 is a soft 404, and it hides missing redirects inside what looks like a healthy site.
• Remove basic authentication from production.
• Confirm the analytics tag you already rely on is present on the templates, including articles.
• If you are a local business, open the Google Business Profile website link and the major directory listings you control. They should land on a 200, not on a chain and not on a 404.
• Read robots.txt and a page of source one more time after the DNS change, not only before it. Caches and the wrong environment have a habit of showing up when traffic does.
Search Console for the first 30 days
Day one and day two, open the page-indexing report. The patterns that matter early are excluded by noindex, not found, redirect error, and a sudden pile of crawled-but-not-indexed URLs that share a template. Inspect a URL from each pile so you are fixing a cause, not a symptom.
Through the first week, add redirect rows for old URLs that 404 and still get requested. The log and the Search Console list will both be longer than your original spreadsheet. That is normal. The map was a forecast. The logs are the census.
Compare the performance report to the previous 28 days for the same pages, and expect noise. A cliff that hits one section—all articles, or all service URLs—usually tracks a shared mistake: a template noindex, a canonical, a navigation drop, or a redirect rule with a typo. A gentle wobble across the whole site is a poor reason to rewrite every title in week one.
Change one class of issue, then watch. Request indexing for the few URLs that matter and are stuck, not for the entire site in a burst that teaches you nothing. At day 30, export pages and queries again. Add the redirects you still missed. Only then decide whether titles or copy on specific URLs deserve a revision, using the queries those URLs already had.
Keep the redirect map after day 30. The first month tells you about errors. It does not tell you that old links have finished arriving.
If the redesign should keep the rankings you have
Nightcoders designs and builds marketing sites and web applications from San Diego, and we treat crawl paths, metadata, and redirects as part of the build when the site is public. See web design and development in San Diego, web development, and SEO.
If you are planning a redesign and you already have pages that earn traffic, contact Nightcoders with the current domain and a note on which sections matter. We would rather map URLs before we debate typefaces, and we will say so if the project in front of us is a content problem wearing a design budget.
Organic growth without gimmicks
SEO & growth works best when technical fixes, content, and how you actually sell stay aligned. We implement alongside engineering when needed—not only slide recommendations.
Read case studies tied to web launches, then get in touch if you want an audit-oriented discussion.