SEO • REDESIGN
A redesign can improve UX, conversion and technical quality, but it can also remove years of organic-search signals in a single deployment if URLs, content and internal links are changed without a plan.
Short answer: what should you check before a redesign?
Before rebuilding a website, inventory the existing URLs, identify pages with organic traffic and backlinks, export Search Console data, preserve good URLs where possible, prepare an old-to-new URL map, plan permanent redirects, compare old and new content, review canonicals and internal links, protect staging, test tracking and forms, crawl the new site before launch and monitor Search Console after publication.
1. Make a list of all existing URLs
Do not start with the new sitemap. Start with the site that already exists. Collect URLs from a crawl, XML sitemap, Search Console, analytics, backlink tools, CMS and server data where available.
Why is the sitemap alone not enough?
It may omit old pages that still receive links or traffic, include redirects, or fail to list legacy URLs that Google still knows. A migration plan needs the real historical footprint, not only the clean list you wish the site had.
2. Mark URLs that already have SEO value
For each important URL, note clicks, impressions, top queries, average position, backlinks, conversions and business importance.
A simple table
| Old URL | Traffic / visibility | Links | Business role | New URL | Action |
|---|---|---|---|---|---|
| /service-a/ | High | Yes | Lead generation | /service-a/ | Keep |
| /old-page/ | Low | No | Obsolete | — | Remove |
3. Check Google Search Console before making changes
Export enough historical data to understand which queries and pages Google already associates with the site. Look at clicks, impressions, CTR, position, indexing reports and sitemap status.
Especially important
Identify pages close to the top 10, pages with strong impressions even if they have few clicks, URLs that lost visibility recently, queries for which a particular page is clearly established and sections with indexing problems that should not be copied into the redesign.
4. Do not evaluate a page only by clicks
A page with few clicks may still have strong impressions, rank for valuable queries, support another page through internal links or receive important external links. “No traffic last month” is not enough reason to delete a URL.
5. Check backlinks to individual pages
Backlinks often point to deep URLs, not only the homepage. If those pages disappear, their value can be lost or diluted.
What should you do?
Keep the URL when the page still has a valid role. When it must be replaced, redirect it to the closest meaningful new equivalent and update high-value external links when you have access to the publisher.
6. Keep good URLs when there is no reason to change them
A redesign does not require new slugs. Stable URLs reduce migration risk, preserve existing signals and avoid unnecessary redirect chains.
Do not change a URL simply because the new one looks “cleaner”
If the old URL is relevant, indexed, linked and already ranks, cosmetic improvement alone is rarely a strong reason to replace it.
7. Prepare an old URL → new URL map
Every changed or removed URL needs a deliberate decision: keep, redirect, merge, remove with 404/410, or replace with another page.
The mapping should be semantic
Redirect an old service page to its real successor, not automatically to the homepage. A redirect should preserve user intent.
8. Use permanent redirects for permanent changes
When an old URL has permanently moved to a new equivalent, use a permanent server-side redirect. Internal links, canonical tags and the sitemap should then point directly to the new URL.
9. Avoid redirect chains
Do not create old A → old B → new C when A can go directly to C.
Before launch
Resolve chains created by previous migrations and point historical redirects straight to the final current destination whenever it is safe to do so.
10. Check canonical tags
Every indexable page should declare the intended canonical version. Watch for copied canonicals from staging, canonicals pointing to old URLs, canonicals to redirects and templates that accidentally point several pages to one address.
11. Update internal linking
Do not rely on redirects for the site’s own links.
Check:
- main navigation
- footer
- breadcrumbs
- service links
- article links
- CTA buttons
- related-content modules
- image and asset URLs
12. Make sure the sitemap contains the new canonical URLs
After migration the XML sitemap should contain only the URLs that should be indexed, return 200 and represent the preferred canonical versions. Remove redirects, old URLs and noindex pages.
13. Staging: do not rely only on noindex for protection
A development copy should not become a public duplicate of the live site.
A safer approach
Use authentication, IP/network restrictions or another access-control layer, and keep noindex as an additional search directive where appropriate.
The biggest risk
A staging environment is copied to production with its noindex settings intact, or staging itself becomes indexable and starts competing with production.
14. Do not move staging robots.txt to production
A Disallow: / rule useful during development can block the entire production site after launch. Check the production robots response separately.
15. Compare title tags and H1 before migration
Design changes often simplify headings or replace informative text with marketing slogans. Before launch compare the old and new title/H1 for important pages.
Example
If an established page clearly says “WordPress Development” and the redesign changes its main heading to “Build something remarkable”, visual character has replaced information search systems and users need.
16. Compare old and new content
Do not assume that “cleaner” automatically means better.
Redesigns often remove content for visual simplicity
Service details, questions, locations, specifications or decision-support content can disappear even though they are part of why the page ranks and converts. Decide what should be shortened and what must be preserved.
17. Preserve content with its own SEO history
When a page has earned rankings, links or long-term impressions, preserve the useful information even if the visual presentation changes.
Better approach
Rewrite and improve outdated sections while keeping the page’s role and the information users still need, rather than replacing everything with generic new copy.
18. Check cannibalisation before reorganising the site
A redesign is a chance to decide which URL owns each main intent. If several old pages compete for the same topic, define whether to merge them, differentiate them or redirect weaker versions.
19. Do not create a new page for every keyword variation
Different phrases do not automatically mean different user needs. Keep the principle: one main search intent should have one main URL unless the SERP clearly shows separate intents.
20. Check structured data
Review schema types, URLs, breadcrumbs, organisation data, products, articles and other markup after templates change. Structured data must still match visible content and real business facts.
21. Check images and important assets
Do not lose externally linked images, critical files or media used by high-value pages. Verify image paths, dimensions, formats, alt text where relevant and lazy-loading behaviour.
22. Core Web Vitals — measure before and after
Save baseline performance before the redesign. After launch compare LCP, INP and CLS using field data when available.
Do not compare only one Lighthouse run on one URL
Test representative templates and real devices. A homepage score does not prove that product, article and service templates perform equally well.
23. Mobile — test real journeys
Do more than resize the browser.
Important for SEO and conversion
- navigation
- forms
- phone/contact actions
- product variants and checkout
- tables and accordions
- sticky elements
- content order and CTA visibility
24. Forms and conversions
A redesign can look perfect while silently breaking lead generation.
Before launch
Test every form, confirmation state, email delivery, phone link, booking link, payment path and other primary conversion from start to finish.
25. GA4 and GTM
Verify that analytics and tag containers are present only once, consent behaviour is correct, events still fire and important conversion names remain consistent enough for before/after comparison.
26. Search Console verification
Make sure ownership still works, the correct domain/property is monitored and the new sitemap can be submitted immediately after launch.
27. A domain change is a separate risk category
Changing templates on the same domain is not the same as changing the domain itself.
Example
Moving from oldbrand.pl to newbrand.com requires a complete domain-level redirect and verification plan in addition to page-level mapping.
28. Change of Address — only when changing a domain or subdomain
Google’s Change of Address workflow is relevant to genuine domain/subdomain moves, not to a normal redesign that keeps the same host.
29. Prepare the server for increased crawling after migration
Google may revisit many changed URLs after launch. Ensure the server, cache and firewall can handle crawling without returning intermittent 5xx responses or blocking legitimate bots.
30. Plan the launch for a sensible time
Avoid a major migration just before the weekend, a critical campaign or a period when nobody can monitor logs, forms and Search Console. The team should be available to react.
31. Prepare a rollback — but use it carefully
Know how to restore the previous version if the new site is genuinely broken. At the same time, repeated switching between old and new structures can create its own crawling and redirect confusion, so rollback should be a controlled emergency option.
32. Crawl staging before launch
Check status codes, links, canonicals, headings, titles, noindex, sitemap logic, structured data and asset paths while the new site is still isolated.
Then compare it with production
Use the old URL inventory to identify missing pages, changed slugs and content that has disappeared unintentionally.
33. Crawl the site again after launch
Production can behave differently from staging.
Minimum after launch
- 200/3xx/404/5xx status review
- redirect map verification
- canonicals and robots
- internal links
- sitemap
- forms
- analytics and key events
34. Monitor Search Console for the following weeks
Monitor:
- indexing changes
- clicks and impressions
- important query/page pairs
- 404s and redirect problems
- canonical changes
- Core Web Vitals
Short-term fluctuations can happen, but large unexplained losses should be investigated quickly.
35. Keep redirects for a long time
Do not remove migration redirects after a few weeks. Old links, bookmarks and search-engine references can continue to be used for a long time.
36. Update the most important external links when possible
Redirects are necessary, but a direct link to the current URL is cleaner. Update profiles, directories, partners and other high-value links you control.
37. Do not change things you do not need to change
Changing CMS, design, domain, URL structure, content architecture and analytics simultaneously creates many possible causes when something goes wrong. Preserve stable elements unless the redesign has a clear reason to change them.
38. When is changing a URL worth the risk?
When the old structure is misleading, prevents the new architecture, contains legacy technology or duplication that genuinely needs consolidation. Even then, map the redirect and update all internal signals.
39. What about removed pages with no equivalent?
Do not redirect every removed page to the homepage. If no meaningful successor exists and the content is intentionally gone, a 404 or 410 can be the correct response. If the old page has strong links, consider whether a genuinely useful replacement should be created.
40. A redesign without URL changes still needs SEO control
Templates can change headings, content, canonicals, performance, structured data, rendering and internal links even when every URL stays the same. Stable slugs reduce risk; they do not eliminate it.
41. Pre-redesign checklist
Data
- export Search Console and analytics
- identify traffic, impressions, conversions and high-value URLs
- review backlinks
URLs
- full inventory
- keep stable URLs where possible
- old-to-new mapping
- direct permanent redirects
Content
- compare old/new page roles
- preserve useful information
- resolve cannibalisation
Technical
- canonical, robots, noindex and sitemap
- structured data and assets
- staging protection
UX / performance
- mobile journeys
- Core Web Vitals baseline
- forms and checkout
Tracking
- GA4/GTM
- conversion events
- Search Console verification
Launch
- staging crawl
- production crawl
- redirect verification
- monitoring and rollback plan
From FreenetPro practice: a redesign starts with a map of what must not be lost
The safest redesign does not freeze the old site in place. It separates valuable signals from obsolete structure.
“Change nothing because of SEO”
This can preserve technical debt and poor UX forever.
“Change everything because it will be more modern”
This can destroy useful URLs, content history and established search intent. The better approach is deliberate change: preserve what works and rebuild what has a clear reason to change.
FAQ
Can a redesign hurt SEO?
Yes, especially when important URLs, content, internal links, canonicals or redirects are changed without a migration plan.
Do URLs have to change during a redesign?
No. If an existing URL is useful and still fits the new architecture, keeping it is usually safer.
What if a URL must change?
Map the old URL to the closest meaningful new equivalent, use a permanent redirect and update internal links, canonical tags and the sitemap.
Does a 301 redirect lose all SEO value?
No. Permanent redirects are the standard way to consolidate moved content, but direct stable URLs are still preferable when there is no reason to change them.
Can all old pages redirect to the homepage?
No. Redirects should preserve intent. If there is no meaningful replacement, 404 or 410 may be more appropriate.
How long should redirects remain after a redesign?
Keep them long-term. Old backlinks, bookmarks and historical search references can continue to send traffic for years.
Does the sitemap need updating?
Yes. It should contain the new canonical, indexable 200 URLs and exclude old redirects and obsolete pages.
Is noindex enough to protect staging?
It is a useful directive, but authentication or another access-control layer is safer for a private development environment.
Do I need an SEO audit before a redesign?
It is often useful, especially when the existing website already has organic traffic, backlinks or a complex structure.
Should metadata be copied from the old site?
Preserve what still matches the page and improves clarity, but use the redesign to correct titles and descriptions that no longer reflect the content or intent.
How soon should SEO be checked after launch?
Immediately for technical checks, then continuously over the next days and weeks through crawls, Search Console and conversion monitoring.
The core rule
A redesign should change the experience without accidentally erasing the signals the existing website has already earned. Inventory first, map changes, test before launch and monitor after publication.
