Written by IILL Editorial
Last updated: 26 August 2026
Short answer: preserve every useful old URL. Keep it unchanged or send it, with a server-side permanent redirect, to the closest equivalent new page. Then make canonical tags, hreflang, internal links, and the XML sitemap agree with the new addresses. Monitor indexing, 404s, and enquiry delivery after launch, and keep the redirects for at least one year.
A website redesign is not finished when a new interface appears on the old domain. Existing search URLs, external links, DNS and email records, enquiry forms, analytics, and operational access all need to move safely.
The most important artifact is not the visual mockup. It is a one-to-one map from every old URL to its new destination. Without that map, a better-looking site can turn valuable search visits into 404 pages or accept form submissions that never reach the right person.
Signs that a website redesign is due
Compare a focused improvement with a full redesign when several of these problems recur:
- navigation, tables, or forms are difficult to use on mobile;
- services and team information no longer match the real organisation;
- nobody knows who controls the domain, hosting, or source repository;
- pages share duplicate titles and descriptions, or search traffic is invisible;
- enquiries arrive through unmeasured or unreliable paths;
- every copy change depends on a vendor and leaves no history;
- or old plugins and administrator accounts make security updates difficult.
If only the visual language is dated, improving the design system and key pages may be enough. If URLs, content, permissions, and conversion paths are tangled together, migration planning belongs in the redesign scope from day one.
Website redesign SEO considerations: what to preserve before work starts
Existing URLs and search entry points
Crawl the current site and list successful pages, redirects, and errors. Mark pages with Search Console impressions, external links, organic visits, or completed enquiries. A page should not disappear merely because it is absent from the new navigation; decide whether its purpose is retained, consolidated, or genuinely retired.
Domain, DNS, and business email
Record the domain registrant, billing account, DNS administrator, and renewal date. DNS often controls business email and external verification as well as the website. Replacing the entire zone for a launch can keep the site online while silently breaking email.
Content, media, and licences
Back up copy, original images, logos, documents, and articles. Verify that font, stock image, theme, and plugin licences still permit use on the new site. Possessing a file is not the same as holding the right to republish it.
Enquiry and analytics baselines
Capture four to eight weeks of enquiries, important landing pages, CTA clicks, and form completions before launch. Separate calls, email, messaging, bookings, and downloads so the redesign can be compared against real outcomes rather than one combined click count.
Build the URL migration map
Use a table with at least these fields:
| Old URL | Current value | New URL | Treatment | Verification |
|---|---|---|---|---|
/old-service |
Organic visits | /services/core |
301 redirect | Search intent remains aligned |
/team/kim |
Current profile | /experts/kim |
301 redirect | Profile and internal links |
/event-2021 |
Retired | None | 410 or useful notice | External links and alternatives |
/contact |
Conversion page | /contact |
Keep | Form, email, analytics |
Google’s site-move guidance recommends mapping old URLs to new URLs, using permanent server-side redirects, and updating canonicals and sitemaps together. Sending every old URL to the new home page removes the relationship users and search engines need.
Seven signals must agree with the URL map:
- Redirects: send each changed URL to its final relevant destination with a server-side permanent redirect, without an avoidable chain.
- Canonicals: make every new page point to its own preferred new URL, not to the retired address.
- Internal links: update navigation, body links, and footers to use the new URLs directly rather than relying on redirects.
- hreflang: when language alternates are used, update every locale to the new URL and keep the references reciprocal.
- Sitemaps: submit the indexable new URLs. During the move, the old URL list can also help Google monitor redirected addresses.
- Monitoring: verify the relevant old and new Search Console properties, then watch indexing, redirect errors, and the queries that used to arrive.
- Retention: keep redirects for at least one year so delayed crawls and external links still reach the intended page.
Choose the migration treatment by what actually changes
“Redesign” can describe four different migrations. The checks are not interchangeable, so name the change before estimating the work.
| Change | Main SEO risk | Required treatment | Launch evidence |
|---|---|---|---|
| New design, same URLs and domain | Important content or headings disappear | Keep useful copy, canonicals, internal links, and status codes stable | Before-and-after crawl plus representative page comparison |
| New paths on the same domain | Old search and external-link entry points return errors | One-to-one permanent redirects and updated internal links, canonicals, and sitemap | Every mapped old URL reaches its closest relevant destination in one hop |
| New domain | Search signals, ownership, and email or DNS records split | Verify both properties, preserve DNS records, redirect old URLs, and monitor both hosts | Old and new properties, redirects, mail, forms, and analytics all verified |
| New platform with the same public structure | Rendering, robots, forms, or analytics change underneath stable URLs | Compare rendered content and response headers, not screenshots alone | Mobile, structured data, form delivery, analytics, and crawl checks pass live |
If more than one row applies, combine the controls. A platform change with new paths and a new domain is three migrations, even when it appears as one design project in a proposal.
Pre-launch redesign checklist
- Every old URL has a reviewed destination or retirement decision.
- Important pages retain a clear title, H1, description, and purpose.
- Changed URLs redirect permanently to the closest relevant page.
- Canonicals, hreflang, robots rules, and sitemaps match the new structure.
- DNS changes preserve business email and verification records.
- Mobile navigation, validation errors, completion states, and keyboard use work.
- Test enquiries reach the real owner and required replies are delivered.
- Analytics and advertising conversions fire once, with useful labels.
- Repository, deployment, domain, and analytics ownership is documented.
- The team has a rollback path and a named launch owner.
What to check after one day, one week, and four weeks
On day one, verify status codes, redirects, TLS, form delivery, analytics, and business email. During the first week, review 404 logs, Search Console indexing, mobile usability, and Core Web Vitals. At four weeks, compare organic entry pages, completed enquiries, and key-page exits with the captured baseline.
Rankings can move after a launch. Do not respond by changing dates or producing many near-duplicate keyword pages. Fix missing redirects, lost content, and crawl problems first.
Before the new site goes live, confirm that you can take it back. The website handover checklist covers domain, deployment, and measurement ownership; the restore test covers the rollback path this checklist assumes.
Next action: build the old-URL inventory before design work is approved. Export the current URLs, mark the ones with impressions, links, or completed enquiries, and bring that table to the kickoff. If you want a second review, start a project enquiry or examine IILL’s professional-practice website portfolio.
Need a clearer first step for your website?
Start with the situation and outcome. We will help define the scope and next step.