A Practical SEO Guide for Website Redesign and Migration
SEO for a website redesign and migration is the work that stops Google treating your new site as a stranger. You crawl what you have, map every URL to a new one, put 301 redirects in place, keep or improve the pages that already bring in enquiries, then watch Search Console for a few weeks after launch. Skip that sequence and you can lose a large share of organic traffic even if the new design looks better.
What actually changes, and what Google notices
A redesign can be templates, copy and page layout on the same URLs. A migration is a move of platform, hosting, domain, URL structure, or all four. Most small business rebuilds are both. Google does not care that your new site looks cleaner. It cares that each useful URL still answers the same intent, returns a 200, and points to a clear canonical.
On a typical UK brochure site of 20 to 50 URLs, a careful move often shows a 10 to 25 percent dip in organic clicks for two to six weeks, then a recovery if the important pages still exist. A sloppy move (homepage redirects, dropped service pages, a new CMS that ships noindex) can cut organic traffic by half and keep it there. Ecommerce or directory sites with hundreds of URLs carry more risk because one missed pattern, such as leftover filter URLs, multiplies 404s overnight.
Audit the live site before anyone designs a thing
Do this on the current domain, not from memory. I export a full crawl first. Screaming Frog’s free tier covers 500 URLs, which is enough for most small business sites. Paid licences start at around £149 a year if you need more.
Capture, for every URL:
- Status code, redirect hop, and final URL
- Title, H1, meta description, canonical
- Word count and whether the page is thin or duplicated
- Internal inlinks, so you know which pages the site itself treats as important
- Indexability: noindex, robots.txt blocks, canonicals pointing elsewhere
Then pull 12 to 16 months from Google Search Console: clicks, impressions and top landing pages. Pull 90 days of analytics for those same pages, including enquiry or call events if you have them. Note the XML sitemap, robots.txt and whether www and non-www already resolve one way. Screenshot the top 20 landing pages. That snapshot is what you compare against after launch. Without it you will argue about whether traffic fell because of the rebuild or because a quiet month landed at the same time.
Map every URL before the new information architecture is locked
The URL map is the SEO document that matters. One row per old URL, a destination, a reason, and a status code. Build it in a spreadsheet while the sitemap is still a sketch, not after the developer has already invented new slugs.
Rules I stick to:
- If the page still exists and covers the same topic, keep the URL. Changing /plumbing-tunbridge-wells/ to /services/plumbing/ for neatness costs you a redirect you did not need.
- If two thin pages become one stronger page, 301 both old URLs to the survivor.
- If a page is genuinely retired, 301 it to the closest equivalent, never the homepage by default.
- Parameter and trailing-slash variants belong in the map too, or they become duplicate-content noise.
| Old URL situation | Action | Status |
|---|---|---|
| Same topic, keep the page | Reuse the path if you can | 200 |
| Same topic, new path | One-hop redirect to the new URL | 301 |
| Two pages merged | Both old URLs to the new combined page | 301 |
| Gone, close equivalent exists | Redirect to the nearest useful page | 301 |
| Gone, no equivalent | Custom 404 with links, or 410 if you want it dropped fast | 404 or 410 |
| HTTP, www, or slash duplicate | Canonical host and slash rule, then 301 | 301 |
A 30-page site usually produces 40 to 80 rows once you include old blog posts, PDF leaflets and leftover campaign landing pages. Budget half a day to a day for that map. Doing it after launch is how chains and homepage dumps happen.
Redirects, hosts and the mistakes that leak equity
Use 301 for permanent moves. A 302 tells Google the move is temporary, so rankings often stay attached to the old URL until it disappears. One hop only: old URL to final URL, not old to interim to final. Chains waste crawl budget and dilute the signal.
Treat these as separate jobs, not one plugin toggle:
- http to https
- www or non-www, pick one and stick to it
- Trailing slash policy
- Uppercase paths if the old CMS allowed them
- Index.php or .html leftovers from an older platform
On Apache this is RewriteRule in .htaccess. On Nginx it is a map or a set of rewrite lines. WordPress sites often use a redirect plugin for one-off rows and server config for the host-wide rules. Test at least 50 old URLs on staging with a crawl before you touch DNS. After go-live, keep the map for 12 months at a minimum. Important commercial URLs should redirect indefinitely.
Never 301 the entire old site to the homepage. Google treats that as a soft 404 pattern. You will see coverage errors and a sharp drop on every landing page that used to rank.
Content, titles and internal links on the new templates
Designers like short pages. Ranked pages usually are not short. If a service page already brings in traffic, do not cut it from 800 words to a three-line blurb plus icons. You can rewrite it, add clearer headings and better photos, but the substance has to remain.
I leave title tags and H1s close to the old versions on pages that already perform, then adjust later one cluster at a time. Changing every title on launch day makes it impossible to tell whether a drop came from the move or from the copy. Recreate the internal links that mattered: home to main services, services to related services, and any location pages that fed enquiries. Broken internal links after a CMS move are common and easy to miss without a recrawl.
Images: keep filenames where they already describe the work, compress them, and write alt text that names the service and town if that is genuine. If you had structured data (LocalBusiness, opening hours, FAQ), put equivalent markup back. Losing it is not fatal, but it is a needless extra change on the same day as everything else.
Platform, domain and hosting moves
Same domain, new CMS is still a migration. WordPress to a page builder, or a builder to hand-coded pages, will change URL patterns, canonical output and the sitemap unless you force them to match the map.
A new domain is a bigger job. Verify both properties in Search Console, use the change of address tool, and 301 every old URL on a 1:1 basis where the page still exists. Keep the old domain on hosting that can serve those redirects for at least a year. Do not run the redesign, the domain change and a brand-new URL scheme on the same night unless you have no choice. Each extra variable makes diagnosis slower.
Hosting still affects SEO through speed and uptime. For a small UK business site I treat a server in the UK or nearby EU, TTFB under about 600ms on a key template, and HTTPS with a valid certificate as the baseline. Staging must send noindex (or be locked) so Google does not index duplicate drafts. The production sitemap should list only 200 URLs you want indexed, and it should be submitted on launch day.
A launch sequence that you can actually follow
- Freeze the URL map and get the client to sign it off. Last-minute slug changes undo the redirects.
- Put 301s on staging and crawl them. Fix chains, loops and accidental 302s.
- Confirm titles, H1s, canonicals, robots.txt and the XML sitemap on staging.
- Lower TTL on DNS 24 hours before cutover so the switch propagates faster.
- Go live. Fetch a handful of key URLs in Search Console’s URL inspection tool and request indexing on the homepage and main service pages.
- Submit the new sitemap. Remove or update the old one if the CMS still publishes it.
- Recrawl within 24 hours. The hit list is 404s, redirect chains and noindex left on from staging.
The first eight weeks
Organic traffic is noisy for a fortnight. I do not tear the site apart on day five. I do watch Search Console daily for coverage spikes: not found, redirected, excluded by noindex, duplicate without user-selected canonical. Compare the top 20 landing pages at week 1, week 4 and week 8 against the pre-launch export. If a page that used to earn clicks now 404s, that is a map error and you fix it the same day. If the page is live, 200, and internally linked, give Google time.
A second full crawl at week 2 catches plugin or CDN quirks that only appear under real traffic. Keep a short log of what you changed after launch so you can correlate dips. Mixing a redesign with a Google Ads pause or a NAP change on directories will muddy the picture.
What this work costs in the UK
The SEO slice is separate from the visual design, even when one person does both.
| Approach | Fit | Typical extra cost |
|---|---|---|
| Do it yourself | Under 30 URLs, you can use a spreadsheet and Search Console | Your time, plus about £0 to £150 for crawl software |
| Freelancer add-on | 30 to 80 URLs, you want the map and redirects done properly | £400 to £1,500 |
| Agency migration SEO | Large sites, domain change, or ecommerce | £1,500 to £5,000 and up |
Those figures sit on top of the rebuild itself. A small business site in the UK still commonly lands somewhere in the low thousands as a one-off project, or as a setup fee plus a monthly amount that covers hosting, updates and ongoing management. The monthly route suits you if there is no lump sum and you want someone else to keep the redirect map and Search Console in view after launch. I offer both a one-off build and a pay-monthly plan; current figures are on arlowebstudio.com rather than here, because they change with scope.
What I would not do is pay for a redesign with no URL map in the contract. If a quote is silent on redirects, sitemaps and Search Console, you are buying a new coat of paint and hoping Google notices the old addresses. Ask for the map as a deliverable, in writing, before anyone opens a design file.
Frequently asked questions
How long does organic traffic take to settle after a move?
On a small site with a clean 1:1 map, expect two to six weeks of noise, then a return towards the old baseline if the important pages still exist. Larger sites or a domain change can take two to three months. A drop that is still steep at week 8 usually means missed redirects or content that was cut, not Google being slow.
Should you change domain at the same time as the redesign?
Only if you must. A new domain plus new templates plus new URLs gives you three variables and no clean test. Prefer keeping the domain and as many paths as you can. If the domain has to change, verify both properties in Search Console, 301 every old URL, and leave the old domain serving those redirects for at least a year.
What if the new site has fewer pages than the old one?
That is fine if the retired URLs 301 to a close equivalent. Merge thin or overlapping service pages onto one stronger page and point both old paths at it. Do not delete blog posts or location pages that still earn clicks unless you have a real replacement. Fewer indexed URLs is not a ranking strategy on its own.
Is a staging site enough to protect SEO?
No. Staging is for testing redirects, titles and the sitemap. It must be noindexed or passworded so it never competes with the live domain. Protection on the live site still comes from the URL map, 301s, content that matches the old intent, and a recrawl after DNS has moved.
Do you need Search Console access before launch?
Yes. Without it you cannot snapshot landing pages, submit a sitemap, inspect URLs or see coverage errors. If an old developer holds the only login, get that transferred before anyone books a go-live date. Analytics alone will not show indexation problems.
Can you keep old URLs when you change platform?
Usually, yes, and you should try. Most CMS tools let you set custom slugs. Matching the old paths removes a large block of redirect work and is the single cheapest SEO decision on a rebuild. Only invent new paths where the old ones were messy, insecure or genuinely wrong.