A redesign loses search visibility when URLs change without redirects, useful content disappears, internal links break or the new site cannot be crawled. None of that is inevitable. If you inventory what you have, map every old URL to a sensible new one, keep the content that earns traffic and monitor closely after launch, a redesign can hold or improve rankings. Expect some fluctuation, though: Google’s own guidance warns that rankings can move for a while after a move.
This plan follows Google Search Central’s documentation on site moves and redirects, and it works whether you are changing platform, structure, design or all three.
First, decide what is actually changing
Google’s guidance on site moves advises changing only one thing at a time where possible (Google Search Central: site move with URL changes). Classify your project:
| Scenario | Risk | Key tasks |
|---|---|---|
| Visual redesign, same URLs and content | Lower | Content parity, metadata, speed, internal links |
| New platform, same URLs | Medium | Replicate URL structure exactly, test crawling, check server and rendering |
| New URL structure, same domain | Higher | Full URL inventory, 301 map, updated sitemaps and internal links |
| New domain | Highest | All of the above plus Search Console Change of Address and verified old and new properties |
If you can keep URLs the same, do. A URL that does not change needs no redirect. Google also says to use readable, descriptive URLs with hyphens, minimal parameters and consistent case, so a redesign is the moment to fix problems, but weigh each URL change against its risk (Google Search Central: URL structure).
Step 1: Inventory the current site
Before design begins, record every URL on the current site and what it does. Combine several sources, because no single list is complete:
- A crawl of the live site.
- Your current XML sitemap.
- Search Console performance data (which pages get impressions and clicks).
- Analytics (which pages get visits and conversions).
- Backlink data for pages other sites link to.
For each URL, note its title, main topic, traffic, conversions, links in and any known issues. Mark each as keep, improve, merge or retire. Pages with traffic, conversions or valuable links are your priority list. Do not retire them casually.
Step 2: Plan content parity
Search engines rank content, so a redesign that thins it out risks traffic. Content parity means the pages that earn visibility keep their substance on the new site: headings, body copy, key facts, images with useful alt text, titles and meta descriptions, and structured data where used.
This does not mean copying everything forever. You can improve, consolidate and cut weak pages. The rule is to do it deliberately and not by accident of the new template. Particular traps:
- Text moved into tabs, carousels or images that the new design hides or does not render as HTML.
- Titles and descriptions reset to generic defaults.
- Content that loads only through JavaScript. Google’s JavaScript guidance notes that rendering is a separate phase and recommends server-side rendering or pre-rendering (Google Search Central: JavaScript SEO basics).
- Canonical tags, robots directives or
noindexleft over from a staging site.
Redesign is also the time to check whether the new layout supports your goals. See what makes a business website convert so that the new design improves enquiries as well as appearance.
Step 3: Build the redirect map
If any URL changes, create a one-to-one map from each old URL to its closest equivalent on the new site. Google’s guidance is specific:
- Use server-side permanent redirects (301 or 308) where possible.
- Avoid redirect chains and point to the final destination directly.
- Do not send many old URLs to an unrelated page such as the home page.
- Test the redirects before launch, using a crawler or the URL Inspection Tool.
(Google Search Central: site move with URL changes)
Google’s redirect documentation explains that permanent redirects signal that the target should be treated as the canonical URL, while temporary ones keep the original page in results, and it says to use permanent redirects when you are sure they will not be reverted. Server-side redirects are preferred, and JavaScript redirects are a last resort because rendering can fail (Google Search Central: redirects).
A simple map is a spreadsheet:
| Old URL | New URL | Redirect type | Notes |
|---|---|---|---|
| /services/web-design-brisbane | /services/web-design | 301 | Merged with generic page |
| /blog/2019/old-post | (no equivalent) | Relevant parent or error page | Low value; do not redirect to home |
For genuinely retired pages with no equivalent, a relevant parent page is acceptable, but do not funnel hundreds of unrelated URLs to the home page.
Also plan to keep redirects for as long as possible. Google generally recommends at least one year, so that signals transfer to the new URLs, and says to update internal links and important external links to point to the new URLs directly because redirects add delay for users.
Step 4: Protect internal links, navigation and sitemaps
Internal links tell Google and visitors which pages matter. Google says every page you care about should be linked from at least one other page, and that links should be <a> elements with an href and descriptive anchor text (Google Search Central: crawlable links). After the redesign:
- Update internal links to point to final URLs, not to redirecting ones.
- Check that your menus, footers and in-content links are standard crawlable links, not script-only controls.
- Keep contextual links between related pages.
For sitemaps, Google advises building a sitemap of the new URLs and submitting it in Search Console, and keeping a sitemap of the old URLs to track progress while they are redirected. Search Console may warn about redirecting URLs in the old sitemap, which you can ignore, and you can remove the old sitemap once the new one is in use (Google Search Central: site move with URL changes). Google notes sitemaps do not guarantee crawling or indexing, and smaller sites with strong internal linking may not strictly need one (Google Search Central: sitemaps overview), but during a migration they are a useful monitoring tool.
Step 5: Check performance and technical health before launch
A slower new site can undo SEO gains. Run your key templates through PageSpeed Insights and aim for “good” Core Web Vitals in lab data before launch. The published thresholds are LCP at 2.5 seconds or less, INP at 200 milliseconds or less and CLS at 0.1 or less (web.dev: Web Vitals). See our Core Web Vitals guide for fixes.
Other technical checks on the staging or pre-launch site:
- Every key page returns a 200 status and has one canonical URL.
- No stray
noindexand robots.txt does not block the site. - Titles, descriptions, headings and structured data carried over.
- Mobile layout works and images have dimensions.
- Forms, phone links, analytics and conversion tracking function.
- A custom 404 page exists, and removed pages return a proper error rather than a soft 404.
- The platform choice fits the team. If you are considering a change, read Astro vs WordPress before committing.
Step 6: Launch checklist
Google recommends moving during a period of low traffic, and says small and medium sites should generally move all at once (Google Search Central: site move with URL changes).
On launch day:
- Confirm the redirect map is live and test a sample of old URLs, including top landing pages.
- Verify all property variants in Search Console (www, non-www, HTTP, HTTPS) and make sure verification methods carry over.
- Submit the new sitemap.
- If the domain changes, submit the Change of Address for the old site.
- Confirm analytics and conversion events record correctly.
- Make sure the new server can handle increased crawling.
- Remove staging protections and block rules.
Step 7: Monitor for weeks, not days
Google warns that rankings can fluctuate and that recrawling can take weeks or longer. Monitor:
- The Sitemaps and indexing reports in Search Console for errors.
- The performance report: compare clicks and impressions for your priority pages against the pre-launch baseline.
- Crawl errors and 404s, fixing redirect gaps as they appear.
- Conversions in analytics, not just traffic.
Keep a baseline export from before launch so you can compare like with like. If a priority page drops, check its redirect, canonical, content parity and internal links before changing anything else.
Frequently asked questions
Do I need a 301 redirect for every URL?
For every URL that has a new address and has any value (traffic, links or users bookmarking it), yes. Redirect each to its closest equivalent. For pages with no equivalent, a relevant parent page or a proper error is better than sending everything to the home page.
How long should redirects stay in place?
Google generally recommends keeping them for as long as possible, at least one year.
Where Radiance Impact fits
Radiance Impact’s Technology division handles website redesigns and maintenance, and its Growth team covers search visibility and SEO. If you are planning a redesign and want the URL and redirect work scoped properly, see our Technology services, our Growth services or contact us.
Sources
- Site moves with URL changes, Google Search Central
- Redirects and Google Search, Google Search Central
- URL structure best practices, Google Search Central
- Crawlable links, Google Search Central
- JavaScript SEO basics, Google Search Central
- Sitemaps overview, Google Search Central
- Web Vitals, web.dev (Google)
