Traffic dropped after a website redesign: what to check on a WordPress site, in order

When search traffic falls after a relaunch, the rebuild itself can be the cause in four ways. The new site is still closed to search engines. Old addresses now answer 404. Old addresses redirect to the wrong place, such as the home page. Or the pages that brought visitors were removed or emptied. The first three can be read off the site in minutes with the commands below. The fourth takes Search Console.

This page is for a WordPress site that was redesigned or rebuilt on the same domain and is already live. The list for before and during a rebuild is the website redesign SEO checklist. A move to another host or platform is in how to migrate a website without losing SEO, and a change of the domain is in how to change your WordPress URL.

The four causes, and what each one does

1. Is the new site closed to search engines?

WordPress's own way to close a site under construction is the box "Discourage search engines from indexing this site", under Settings, then Reading. While it is ticked, WordPress prints a robots tag of noindex, nofollow on every page. A staging copy that becomes the live site brings the ticked box with it. Google's guide to moving a site puts a forgotten noindex or robots.txt block first in its list of common mistakes.

This prints the robots tag of the home page. Put your own address in place of https://example.com/.

That answer means the site is closed. A tag that reads max-image-preview:large and nothing else blocks nothing.

Google's page on traffic drops says a misplaced noindex takes effect as Google crawls each page again, so the fall is slower than when a whole site is down. A slide that begins at launch and keeps going fits it.

What the box does and how to turn it off has the steps and the other places a noindex can come from. The page indexing check reads the tag, the headers and robots.txt for one address without a terminal.

2. Make a list of the old addresses

The next two checks need the addresses the old site answered at. These places still hold them.

• Search Console's Performance report. Set the date filter to a period before the launch, choose the Pages tab above the table, and use the export button. These addresses were shown in Google, so they matter most. The report reaches back 16 months.
• A sitemap of the old site, if someone saved a copy.
• A backup of the old site. Its database lists every post and page.
• The Internet Archive. Its help page gives the address that lists every file it has archived for a site: web.archive.org/*/example.com/*, with your own domain. It cannot guarantee that a site was archived.
• Search Console's Page indexing report. The row "Not found (404)" lists addresses Google asked for and got a 404. Google's help says each list there holds examples, up to 1,000.

Save the addresses in a file named old-urls.txt, one full address to a line.

3. Ask every old address what it answers

This asks for each address in the file and prints its status code, the address, and where a redirect points. curl does not follow the redirect, so you see the first answer by itself.

Set the lines beside your export from the Performance report. A 404 on an address that had clicks is the first thing to fix.

A 301 can also point at an address that does not exist: Google's guide says it frequently sees this. The redirect checker follows one address through every hop to its end.

4. What WordPress forwards by itself, and what it does not

WordPress redirects some old addresses without being asked, so a rebuild can look fine on the few addresses someone tried. This is what an old address answered on a WordPress site after each kind of change. The site was on "Post name" permalinks unless the row says otherwise.

A saved slug. When the slug of a published post changes, WordPress stores the old one with the post and redirects the old address with a 301. Its code reference says this is not attempted for kinds of content that have parents and children, and pages are one. The record lives in the database. A site rebuilt on a fresh install, with the content entered again, starts without it.

A guess. When an address finds nothing, WordPress looks for a published post or page whose slug begins with the name in the address, and redirects to the first it finds. That is what forwards a page after it moves under a new parent. It is also what sends a removed page's address somewhere it was never meant to go. On a site with a post at /pricing-changes-for-2025/, removing the page at /pricing/ leaves this:

The line X-Redirect-By: WordPress says WordPress sent the redirect. One made by a rule in the server's configuration carries no such line, so the command also shows where to look for a redirect you did not expect.

For every old address that answers 404 and has a replacement, add a 301 redirect to that replacement. How to set up redirects in WordPress has the three places a redirect can live, and the redirect map builder turns a list of old and new addresses into rules. If the whole permalink structure changed, one rule covers every post: see how to change WordPress permalinks without breaking your old links.

5. Old addresses that all lead to the home page

A rebuild that drops a section can leave one rule behind that sends everything in it to the home page. On Apache it looks like this.

Each old address then answers 301, so a quick look finds nothing wrong. In the loop's output, every line ends at the same address.

Google's guide to moving a site says not to redirect many old addresses to one irrelevant destination such as the home page. In its words, this "might be treated as a soft 404 error". Its page on crawl errors says pages it judges to be soft 404s are excluded from Search. The exception in the same guide is real consolidation: when several old pages were merged into one, they can all redirect to it.

The cure is one redirect for each old address, to the page that replaced it. Take the catch-all line out and put lines like this one at the top of .htaccess, above # BEGIN WordPress.

An old address with no replacement gets no redirect. It answers 404, which the next section covers.

6. Pages that were removed or emptied

Removed. A page that is gone answers 404, unless WordPress guesses as in section 4. Google's documentation gives two answers, by case. If the page has moved or has a clear replacement, return a 301 to it. If it was removed and nothing on the site replaces it, a 404 or a 410 is the right answer, and Search Console's help says such a 404 is not necessarily a problem. So look each 404 up in your export. One that brought clicks is a page worth having back.

Where the redesign was done on the same install, a deleted post or page may still be in the Trash. WordPress keeps it there for 30 days unless the site's configuration says otherwise. This lists what is in it.

In the dashboard, the "Trash" link above the list of pages shows the same, with "Restore" under each title. A restored page comes back as a draft, so publish it again.

Emptied. A page that kept its address and lost its text answers 200, so the loop passes it. Search Console shows it instead, as a page that lost clicks while its address still works. Compare its title, headings and text with a copy from before: a backup, or the Internet Archive. What has to arrive on each new page lists what a search engine reads from a page.

7. Read Search Console the way Google's guide says

Google's page on traffic drops gives the method for the two questions the site cannot answer: which pages lost clicks, and since which day.

The pattern narrows the cause. Every page falling together from launch day fits a closed site. A group of pages that shared a pattern in their addresses fits redirects. One or two pages that carried most of the clicks fit a page that was removed or emptied.

In the Page indexing report, look for a rise since launch in "Not found (404)", "Soft 404", "URL marked ‘noindex’" or "Redirect error". Old addresses under "Page with redirect" are the expected result of a redirect that works: Google's help says such an address is not indexed, and its target may be.

8. What else it could be

A fall that follows a launch is not always caused by it. Besides technical issues and site moves, which are this page's subject, Google's page lists these causes.

• An algorithmic update. Google publishes a list of its ranking updates. Compare the dates with the day your fall began.
• A security issue. Check the Security Issues report in Search Console. If it lists anything, see how to check whether a WordPress site was hacked.
• A spam issue. Check the Manual Actions report.
• Seasonality and changing interests. The 16-month view shows a fall that comes every year, and Google Trends shows whether fewer people are searching at all.
• A change in the data. Google keeps a page of data anomalies in Search Console.

9. How long recovery takes, in Google's words

Google gives general rules and no dates.

• Changed addresses. Its page on traffic drops says that, as a general rule, a medium-sized website can take a few weeks for Google to notice the change, and larger sites longer. Its guide to moving a site says visibility may fluctuate temporarily during that time.
• Other changes. The same page says some changes take effect in a few days and others could take several months, and that you will likely want to wait a few weeks before analyzing the site again.
• No promise. It also says there is no guarantee that a change to a website will have a noticeable effect in search results.

Nobody outside Google can turn these into a date for your site.

What to fix first

1. Open the site, if the first check found noindex. It affects every page.
2. Redirect the old addresses that had clicks and answer 404, from the top of the Performance export down.
3. Replace a rule that sends everything to the home page with one redirect for each address.
4. Bring back the pages that brought visitors, or their text.
5. Run the loop again. Every old address with a replacement should answer 301 and lead to it.
6. Leave the redirects in place. Google's guidance is as long as possible, generally at least 1 year.

When to get help

Hand it over when the list is longer than you can check by hand, when nobody kept a record of the old site, or when every check passes and the fall goes on. WP Ministry's SEO audit is a one-time, written audit of what stands between a WordPress site and a search engine. Each finding names the documentation it rests on, the fixes on the WordPress side are done, and each fix is tested again.