A website redesign SEO checklist in five steps

A website redesign SEO checklist matters because a new site changes the things search engines rely on: page addresses, content, titles and internal links. When those are handled deliberately, Google can carry your existing pages over to their new addresses, and the people who found you through search keep arriving at the right page. The steps below run in order: inventory the old site, map every URL, redirect, carry over what worked, launch carefully, then watch Search Console in the weeks after.

Why redesigns lose search traffic

The usual causes are things search depended on that quietly disappeared in the move:

• old URLs change and start returning "page not found" errors
• every old URL is redirected to the homepage instead of its closest match
• pages that ranked are cut or shortened to suit a new layout
• page titles and descriptions are replaced with a template, or left blank
• the staging site's "don't index" setting goes live with the new site
• the new site is heavier and slower on phones than the old one (Core Web Vitals, explained covers how to check)

Even a well-run move causes some movement. Google's guide to site moves with URL changes says to expect temporary fluctuation in rankings, and that a small to medium-sized site can take a few weeks for most pages to move. The point of the checklist is to make sure that fluctuation settles back.

Step 1: crawl and inventory the current site

You can't redirect pages you don't know about. Build one spreadsheet of every URL the old site has, from several sources, because each one misses something:

• a crawl of the live site with a site-crawling tool
• the current XML sitemap
• the Performance report in Search Console, exported by page and by query, which shows the pages that earn clicks
• your analytics, for the pages people land on from any source
• the Links report, which lists the pages other sites link to most
• PDFs, image files, old campaign pages, and any URL printed on flyers, menus, brochures or QR codes

That last group is easy to forget. A restaurant with table QR codes pointing at a menu page, or a clinic whose printed flyers carry a short link, needs those addresses to keep working long after launch.

For each URL, record its title, meta description and main heading, its clicks and impressions, whether other sites link to it, and a decision: keep, merge or remove.

Make those decisions with the numbers in front of you:

• Keep anything that earns clicks, has links from other sites, or does a job for customers, even if it's never visited from search (a parking and directions page, say).
• Merge pages that cover the same topic thinly, such as three short posts about choosing a renovation contractor, into one stronger page, and redirect all of them to it.
• Remove pages with no visits, no links and no purpose, such as an expired promotion. Removing a page is fine when it's a deliberate decision.

Save a copy of the Performance report and the Page indexing report as your baseline. You'll want it in a month.

Step 2: map every old URL to a new one

Where an old address is still sensible, keep it, and it won't need a redirect. Where it must change, write down exactly where it goes.

Old URL	New URL	Action
/services.html	/services/	permanent redirect
/portfolio/tampines-4-room-hdb	/projects/tampines-4-room-hdb/	permanent redirect
/hdb-renovation and /hdb-packages	/services/hdb-renovation/	both redirect to the merged page
/cny-promo-2023	none	return 404 or 410

Google's guidance on redirects is specific, and worth following to the letter:

• Use permanent server-side redirects. Google's redirects documentation explains that a 301 or 308 is a signal to its systems that the new URL should be treated as canonical; a temporary redirect isn't.
• Redirect straight to the final page. Avoid chains where an old URL hops through two or three addresses.
• Don't send everything to the homepage. Redirecting many old URLs to one irrelevant page "can confuse users and might be treated as a soft 404 error". Merging several similar pages into one new page is fine.
• Let dead pages die properly. If content is gone and nothing replaces it, return a 404 or 410.
• Keep redirects for a long time. Google says "as long as possible, generally at least 1 year".
• Cover the variants. http and https, www and non-www, with and without trailing slashes, old .html endings.

Changing domain as well, say from a .com to a .com.sg, is a bigger move. Google's Change of Address tool is for moves between domains or subdomains; URL changes within the same site don't use it.

Step 3: carry over content, metadata and internal links

Content. If a long service page answered real questions and ranked for them, the new version should keep that substance, improved and reorganised if needed, and the design should make room for it. Website copywriting for service businesses has more on writing pages that answer questions.

Titles and descriptions. Carry them over or improve them, page by page. Google's guidance on title links asks for unique, descriptive titles and warns against boilerplate; it may generate its own title from headings or other text when yours isn't helpful. Its snippet guidance makes the same point about identical descriptions across pages.

The rest of the page. Headings, image alt text and structured data all need to survive the move. If the old site had LocalBusiness or breadcrumb markup, check the new templates output it too (schema markup for small businesses explains the useful types).

Internal links. Update navigation, footers, buttons and links inside body text to point at the new URLs directly. Google's migration guide asks for this, and for a self-referencing canonical tag on each new page and a sitemap that lists the new URLs.

Links you control elsewhere. Your Google Business Profile website link, social profiles, directory listings, ads and email signatures should all point at the new addresses. The local SEO guide covers why consistent details matter.

Step 4: the launch-day website redesign SEO checklist

Most new sites are built on a staging address that's kept out of search with a password, a noindex rule or robots.txt. Google's migration guide suggests listing those blocks in advance, so removing them is a planned step on launch day.

1. Put the new site live and remove every noindex rule and robots.txt block used during development.
2. Check the live robots.txt allows crawling of the pages you want found.
3. Test the redirect map: a sample by hand, then every row with a script or crawler. Each old URL should return one permanent redirect to the right page.
4. Check that removed pages return a 404 or 410, and that the 404 page helps people find what they wanted.
5. Submit the new sitemap in Search Console.
6. Run the URL Inspection tool on the homepage and your most important service pages.
7. Update your Business Profile, social profiles and any ads.
8. Test every form, booking link and analytics tag on the live domain, not on staging.

Step 5: monitor Search Console after launch

In the weeks after launch, keep an eye on these:

• Page indexing report. Watch for rises in "Not found (404)", "Soft 404", "Redirect error" and "URL marked 'noindex'". "Page with redirect" for your old URLs is expected.
• Performance report. Compare clicks and impressions page by page against your baseline. A total can look steady while one important page has dropped.
• 404s from real visitors. Check analytics or server logs for old URLs still being requested, and add redirects for any you missed.
• Core Web Vitals report. Once enough real-user data builds up, confirm the new site is at least as fast as the old one.

Check after one week, one month and three months, and leave the redirects in place well beyond that.

On a website redesign, we treat the URL map and redirects as part of the job from the start, along with the SEO groundwork that goes into every build.