Website redesign SEO checklist: what to record, map and check on a rebuilt site

A redesign loses search traffic in three ways. Addresses change and nothing forwards the old ones. Pages that brought visitors are dropped or thinned. Or the new site goes live still closed to search engines. Every item here protects against one of those. None is a way to a better place in the results.

The checklist is for a redesign or a rebuild on the same domain: a new theme, a new structure, new addresses. Google's guide to moving a site counts changed paths on one domain as a site move, so its steps apply. A move to another host or platform is in the website migration checklist, the commands for a move that changes addresses are in how to migrate a website without losing SEO, and a change of the site's own address is in how to change your WordPress URL. If the new site is live and visits have fallen, start with traffic dropped after a redesign.

Before anything is built: record what exists

Save these while the old site still answers.

• Every address it answers at. Google's guide says where to look: the sitemap, analytics or the server's logs, the Links report in Search Console, and the content management system's own list. It counts images and downloads such as PDFs as well. Which sitemap WordPress makes says where yours is, and how to change permalinks safely has a command that prints every post's address. Search Console's Page indexing report cannot make the list: Google's help says it shows an example list of up to 1,000 addresses. To check: the list holds posts, pages, category and tag archives, and files.
• Which pages bring search visitors. In Search Console's Performance report, group the table by Pages and use the export button. Set the date filter to the last 16 months first, so that a page with a season is in it.
• The title and meta description of each of those pages. Google uses the <title> element as a source for the title of a result, and sometimes uses the meta description for the text under it. WordPress prints a title and no meta description by itself, as WordPress SEO without a plugin shows. A description on the old site therefore comes from a plugin or the theme, and a rebuild that drops either drops the descriptions with it. Save each page's source.
• Structured data. WordPress prints none by itself either. Run each of those pages through Google's Rich Results Test and save what it reports.
• The redirects already in place. They can sit in a redirect plugin's list, in the server's configuration, or in WordPress itself: when the slug of a published post changes, WordPress saves the old slug with that post and forwards the old address with a 301. That record belongs to the post, and a post typed in again on a fresh install has none. To check: Search Console lists such addresses under "Page with redirect". Note where each one lands.
• How Search Console is verified. Google's guide says to make sure it keeps working after the move. If it rests on an HTML file, or on a tag in the old theme's templates, the new site has to carry the same one.

The map: every old address to its new one

Put the list in a spreadsheet, one old address to a row, and give every row an outcome.

• An address that can stay, stays. It needs no redirect.
• A changed address gets one new address: the page that replaces it. Use a permanent redirect made by the server, a 301 or a 308. Google shows the new address in results after a permanent redirect, and keeps showing the old one after a temporary one such as a 302.
• Nothing goes to the home page by default. Google's guide: "Don't redirect many old URLs to one irrelevant single URL destination, such as the home page of the new site. This can confuse users and might be treated as a soft 404 error."
• Merged pages go to the page that now holds their content. The same guide allows several old pages consolidated into one to redirect to it.
• A page that is being dropped answers 404 or 410. That is what Google's guide asks for content that is not coming along. First look the page up in the Performance export and the Links report. One with search visitors, or with links from other sites, is one to keep or to replace.
• Old redirects are pointed again. If an address already forwards to a page whose own address is about to change, send it straight to the final one. Google advises against chains.
• Do not count on WordPress to forward for you. It forwards a post whose slug changed, but not a page, and a change of permalink structure can leave every old post address answering 404. How to change permalinks safely has the table.

The redirect map builder turns the two columns into 301 rules for Apache or nginx, in your browser, and points out chains, loops and duplicates. Its rules match the path alone, so it leaves out an old address that has a query string, and that one needs a rule written by hand. Where the rules go on a WordPress site is in how to set up redirects in WordPress.

To check: no row is blank, and every row that points at the home page has a reason.

While building on staging

• The build is closed with a noindex and a password, not with robots.txt. In WordPress the noindex is the box "Discourage search engines from indexing this site". WordPress's documentation says it does not block access and that honoring it is up to search engines, so a password goes with it. Google says a crawler blocked by robots.txt never sees a noindex. What to do when a staging site is indexed by Google has the order to do these in.
• Every block is written down as it is added. Google's guide asks for this: prepare what robots.txt should say once the move starts, and a list of the addresses a noindex has to come off.
• The pages that bring visitors keep what they say. Carry their text over whole and rewrite later. Google's guide says that with any significant change to a site, rankings may fluctuate while the site is recrawled and reindexed.
• Titles, descriptions and main headings match the record. Google asks for a title in the <title> element of every page, distinct from page to page, and also reads heading elements such as <h1> when it picks a result's title. To check: compare the source of each top page on staging with what you saved.
• Internal links name the new addresses. Google's guide says to change them using the map: menus, the footer and links typed into the text.
• Structured data is the same or better. Google says to check it with the Rich Results Test during development, and that it must describe what a visitor can see on the page. The test cannot reach a page behind a password, so choose "Code" and paste the page's source.
• Each page's canonical tag names the page itself. Google's guide asks for a self-referencing rel="canonical" on every new address. On staging it names the staging address, so look again after launch.

Launch day, in order

The day after and the first weeks

• Test the whole map. Every old address should answer 301 and reach the right page in one hop, and that page should answer 200. Google says it frequently sees redirects that point at addresses which do not exist on the new site. The redirect checker takes one address at a time, and a command for a whole list is in how to migrate a website without losing SEO.
• Watch the Page indexing report. Old addresses listed under "Page with redirect" are the expected result: Google's help says such an address is not indexed, and its target may be. What to look for is a rise under "Not found (404)", "Soft 404", "Redirect error" or "URL marked ‘noindex’".
• Watch the Performance report by page. Google's guide to traffic drops says to compare the period with an earlier one and sort the Pages table by "Clicks Difference". Pages that lost clicks together point at their rows in the map. The same guide gives a general rule of a few weeks for Google to notice changed addresses on a medium-sized site.
• Fix the 404s that have visits. The server's logs or your analytics show which missing addresses people still ask for. Google's help says a 404 is not necessarily a problem when a page was removed with no replacement, and that a page which moved should get a 301.

What to keep

• The redirects. Google's words: "Keep the redirects for as long as possible, generally at least 1 year." It adds that for visitors' sake you should consider keeping them indefinitely.
• A note of where they live. Redirects in a plugin's list stop when the plugin is switched off.
• The map and the list. The next redesign starts from them.

What a redesign does not need

• A new domain "for a fresh start". That is a second move on top of the first. Google's guide says to change one thing at a time. Its help for the Change of Address tool says a site move combined with a redesign of the content and the address structure will probably lose some traffic, because Google may need to relearn and reassess the individual pages. If the domain must change, do it as a job of its own: how to move WordPress to a new domain.
• A new address for every page, for tidiness. WordPress's documentation says permalinks "are permanent and should never be changed". Google handles a move one address at a time, and counts it complete only when its crawler has visited every old and every new address at least once.
• Old posts removed wholesale. Google's page on helpful content lists, as a warning sign, removing a lot of older content mainly in the belief that it will help rankings by making the site seem fresh. Its answer is "No, it won't". Look each post up in the Performance export before it goes.
• The Change of Address tool. Google says it is only for a move from one domain or subdomain to another, and is not needed for moving paths within the same domain.

WP Ministry's SEO for a new website is a one-time setup for a new or rebuilt WordPress site. On a rebuilt site, every address the old site answered at is matched to its new one and redirected, and each redirect is checked.