Fixing SEO Issues After WordPress Migration: Start With URL Truth

TL;DR: Your WordPress migration probably did not “hurt SEO.” It broke the trail between old URLs, new URLs, redirects, canonicals, sitemaps, internal links, and now AI citations, so the fix starts with URL truth, not another plugin audit.

The migration did not kill your SEO. The broken URL story did.

Most people diagnose wordpress migration seo problems from the wrong end. They ask whether WordPress, the new theme, the host, or the SEO plugin caused the drop. Sometimes one of those was involved, usually because it broke URL continuity.

At mindnow, I’ve seen WordPress migrations where the content was fine and the rankings still fell because 600 old URLs were quietly pointed at the homepage. I now check that before I check anything on seojuice.com or vadimkravcenko.com.

The fastest wins are usually boring: old URL, new URL, status code, canonical, indexability, sitemap inclusion, and internal links. That is the order — not titles, not schema, not Core Web Vitals.

Joost de Valk, founder of Yoast SEO, framed successful domain migrations as “roughly 90% preparation and 10% execution.” That line is useful after a bad launch too. If the preparation did not happen before cutover, the repair work is preparation done late.

The job is to prove whether Google can still connect old demand to new destinations. If it cannot, rewriting copy is theater.

First, classify the drop before you fix anything

Not every post-migration traffic drop has the same cause. A host move, domain change, permalink change, theme rebuild, CMS import, and SEO plugin swap can all produce the same chart: organic sessions down, everyone nervous.

The first diagnostic fork is simple. Did Google lose the URL, distrust the new URL, or understand the wrong relationship between them?

Do not rewrite content until you know whether Google can reach, understand, and trust the new URL. A post with a noindex tag does not need a better headline. A product category canonicalized to the old domain does not need more copy. A redirected landing page that now resolves to the homepage does not need schema markup.

Classify first. Then repair.

Rebuild the URL map, even if the migration already happened

John Mueller gave the cleanest version of this advice during a Google SEO Office Hours discussion, reported by Search Engine Journal:

“I think the most important part is really to track the individual URLs, so that you have a clear map of what previously was and what it should be in the future.”

“Individual URLs” matters in WordPress. It does not mean only posts and pages. WordPress creates surfaces through themes, plugins, archives, media behavior, filters, and old permalink fallbacks. If you migrated only the visible menu structure, you probably missed half the site.

WordPress URL surfaces people forget

• Posts and pages
• WooCommerce product URLs, product categories, and the /shop base
• Categories, tags, and custom taxonomies
• Author archives
• Date archives if they were indexable
• Attachment pages and media URLs
• Custom post type archives
• Paginated archives
• Feed URLs
• Old ?p=123 permalink fallbacks (yes, those still resolve on older installs)
• Trailing slash and non-trailing slash variants
• HTTP to HTTPS variants
• www to non-www variants
• Old staging or temporary host URLs that leaked

Start with evidence, not memory. Export landing pages from analytics. Export top pages from Google Search Console. Crawl the current site. Pull any pre-migration crawl if one exists. Add backlink URLs from your link index if you have access. Then merge everything into one old-to-new map.

Yes, this is the boring spreadsheet part — it is also where most recoveries start (the audits I have salvaged at mindnow always traced back to a missing column on someone else's earlier sheet). Use columns for old URL, new URL, HTTP status, redirect target, canonical target, indexability, sitemap inclusion, and notes. If there is no equivalent destination, say that. Do not hide it behind a homepage fallback.

For larger sites, prioritize URLs with backlinks, revenue, organic clicks, conversions, or AI citations. A dead tag archive from 2017 can wait. A product category that used to drive non-brand sales cannot.

Fix redirects before you touch titles, copy, or schema

Google’s official site-move documentation says:

“Keep the redirects for as long as possible, generally at least 1 year.”

That line should be printed above every WordPress migration checklist. Redirects disappear in boring ways. Someone removes the .htaccess block. A redirect plugin gets disabled during cleanup. A host migration drops Nginx rules. Cloudflare page rules get replaced. The old domain expires. The staging domain is deleted. Nobody notices until Search Console looks like a crime scene.

A redirect is only useful when the destination answers the same intent. Old blog post to new blog post. Old product to equivalent product. Old category to equivalent category. Old service page to the closest surviving service page. If the destination is irrelevant, the technical 301 does not save the SEO value.

If you need a process, use this:

1. Crawl your old URL list and record every status code.
2. Flag every 3xx chain longer than one hop.
3. Flag every old URL that lands on the homepage.
4. Check whether the final destination is indexable.
5. Confirm the final page canonicalizes to itself or the intended canonical.
6. Move high-value redirects out of fragile plugin rules and into server or edge rules where possible.

If you use a plugin, export its rules before touching anything. Redirection, Rank Math, Yoast Premium, and host-level redirect panels can all work. The problem is usually ownership. Nobody knows which layer is authoritative.

The homepage redirect is not a safety net

Google’s site-move documentation warns against redirecting many old URLs to one irrelevant destination, such as the homepage, because that can be treated as a soft 404. In WordPress, this mistake is common. An admin sees hundreds of 404s in a plugin and creates a global fallback to /. The dashboard looks cleaner — search traffic gets worse.

The fix is slower but safer. Map old URLs to the closest equivalent destination. If there is no equivalent, return a real 404 or 410. Let dead URLs die honestly. Preserve the pages that matter with one-to-one redirects.

This is especially painful for ecommerce migrations. A discontinued product may deserve a redirect to a replacement product or parent category. A deleted product with no replacement may deserve a 410. A deleted product redirected to the homepage teaches Google nothing.

Watch the 180-day Change of Address window

The Change of Address tool in Google Search Console helps Google process a site move, but it is not a substitute for redirects. Google Search Console Help says the migration actions continue for 180 days after you start migration in Search Console (the tool processes signals for that long, not forever).

After that window, Google says it does not recognize the old and new sites as related if the old site is still present and crawlable. The practical lesson is simple: redirects must outlive the Change of Address window. If the old host was shut down in month five, you created a cliff.

Check the WordPress settings that silently block recovery

WordPress rarely breaks one page at a time. It breaks templates. Diagnose by page type, not random URL sampling.

Start with the obvious setting because it still causes real damage: Settings → Reading → Discourage search engines from indexing this site. Staging sites often have it enabled. A rushed launch can carry it into production. Same for SEO plugin noindex rules copied from staging.

Then check canonicals. A theme rebuild or plugin import can leave canonical tags pointing at the old domain, the temporary host, or the wrong language version. Inspect the rendered HTML, not only the plugin field. Cache can serve stale tags after the admin screen looks fixed.

Sitemaps deserve the same suspicion. WordPress SEO plugins split sitemaps by post type and taxonomy. After migration, you may have clean post URLs in one sitemap and old-domain category URLs in another. Submit the sitemap index, then open the child sitemaps manually.

Robots.txt is another quiet killer. Blocking /wp-content/ can stop Google from fetching CSS, JavaScript, or images needed to understand the page. Blocking a template path can hurt whole groups. Blocking the entire site still happens after staging launches. I have seen it more than once.

Permalinks are worse because they look like a content decision. Changing from /%postname%/ to /blog/%postname%/ without redirects creates a URL migration inside the migration. Changing category bases, removing trailing slashes, or altering WooCommerce product bases has the same effect.

Also check redirect rule order, CDN rules, multilingual plugin output, hreflang targets, WooCommerce filter URLs, attachment-page behavior, pagination, breadcrumbs, and custom post type archives. One bad template can suppress hundreds of URLs.

If this feels like a technical SEO audit checklist, good. Post-migration recovery is a technical audit with a timestamp and a suspect list.

Recover pages that disappeared from Google’s index

Pick one valuable page that lost traffic. Not twenty. One.

Inspect the old URL first. Does it return a 301? Does it chain? Does it land on the correct new URL? Does the destination load for Googlebot? Then inspect the new URL. Confirm status code, canonical, robots directives, rendered HTML, internal links, sitemap inclusion, and last crawl date.

Use Google Search Console’s URL Inspection tool for the live URL, not only the indexed version. The indexed version tells you what Google last stored. The live test tells you what Google can fetch now.

Then scale by template. If one migrated blog post has the wrong canonical, all migrated blog posts may have it. If one product category is noindexed, all product categories may be noindexed. If one author archive is suddenly indexable, every author archive may be creating thin pages again.

Search Console validation is slow (days to weeks, not hours). The better early signal is crawl behavior. Check server logs if you have them. Are redirected legacy URLs still being requested? Are Googlebot requests reaching final destinations? Are 404s dropping for high-value old URLs?

Rankings usually recover by group. If repaired product categories start getting crawled and impressions return, apply the same fix to the remaining category set. Do not keep changing unrelated things while the first repair is still being processed.

AI citations add a second migration problem now

Joost de Valk put the new problem sharply:

“There is no Change of Address form for a model that finished training a year before your move.”

Google can crawl redirects. Search Console can process a site move. LLMs and AI answer engines may still carry old hostnames or old URLs in training data, retrieval indexes, partner indexes, or cached citation layers. A clean 301 helps Google but does not rewrite every old citation stored somewhere else.

The fix is not magic. Keep redirects alive. Keep old URLs resolving to the best new match. Update high-authority profiles, canonical source pages, organization schema, sameAs references, XML sitemaps, and internal links. Where possible, update citations on platforms that AI systems commonly ingest.

This matters more for WordPress than people admit (I was wrong about this for years). Many migrations rely on plugins or host rules that get cleaned up after three months. If AI citations still point at old URLs, those redirects are the bridge. Kill the bridge and the citation becomes a dead end.

For adjacent cleanup, read the SEOJuice guides on redirect chains and 301 redirects, XML sitemap best practices, and canonical tag errors.

A 14-day repair plan for WordPress migration SEO

You can recover a messy migration without trying to fix everything at once. The sequence matters more than the tool stack.

Day 0 to 1: stop the bleeding

• Confirm ownership of the old domain, old host, DNS, CDN, and Search Console properties.
• Restore redirect control before editing content.
• Disable homepage catchall redirects.
• Remove accidental noindex tags and robots blocks.
• Submit clean sitemap indexes for the new site.
• Test a sample of old high-value URLs manually.

If you no longer control the old domain, recovery gets harder fast. Regain control before debating title tags.

Day 2 to 4: rebuild the map

• Create the old-to-new URL table.
• Prioritize URLs with backlinks, organic clicks, revenue, conversions, and AI citations.
• Separate URLs by type: posts, pages, products, categories, tags, media, archives, feeds.
• Fix redirects in batches, starting with the highest-value groups.
• Retest every batch after deployment.

Do not trust “all redirects imported successfully.” Crawl the list.

Day 5 to 7: repair templates

• Audit canonicals by page type.
• Check robots directives and noindex rules.
• Review titles, headings, schema, breadcrumbs, and internal links.
• Check pagination and archive templates.
• Confirm multilingual hreflang targets if relevant.
• Test WooCommerce category, product, and filter behavior.

This is also where a WordPress technical SEO review earns its keep. You are looking for template-level failure, not one-off weirdness.

Day 8 to 14: prove recovery

• Monitor Search Console coverage and crawl stats.
• Check logs for Googlebot activity on legacy redirects.
• Track rankings by URL group, not only by keyword.
• Compare analytics landing pages before and after repair.
• Keep notes on every redirect, template, and sitemap change.

If traffic improves on repaired URL groups, scale the same fix. If nothing changes, stop making random edits and recheck the map.

What not to do after a bad WordPress migration

Do not install three more SEO plugins. You will create overlapping canonicals, duplicate sitemaps, and redirect rules nobody owns.

Do not redirect every 404 to the homepage. Google has been clear that irrelevant mass redirects can become soft 404s.

Do not change the permalink structure again because the current one “looks cleaner.” Clean URLs are useless if they keep changing.

Do not rewrite content before fixing access, redirects, canonicals, and indexability. Content quality cannot compensate for a broken route.

Do not remove old redirects because “Google has probably figured it out.” Google’s own guidance says keep them for as long as possible, generally at least one year.

Do not trust the homepage ranking as proof that the migration is fine. Brand recovery can hide template collapse. Check the landing pages that used to bring non-brand traffic.

If the old URLs cannot explain where they went, Google has no reason to guess for you.

FAQ

How long does WordPress migration SEO recovery take?

Small fixes can show crawl and impression changes within days. Ranking recovery usually takes longer because Google has to recrawl old URLs, process redirects, update canonicals, and rebuild confidence in the new URL set. For larger sites, think in weeks, not hours.

Should I resubmit my sitemap after a WordPress migration?

Yes, but only after the sitemap is clean. Submitting a sitemap full of old-domain URLs, noindexed URLs, or canonical mismatches can slow diagnosis. Open the sitemap index and child sitemaps manually before submitting.

Are 301 redirects enough to preserve rankings?

They are necessary, but they are not the whole job. The destination must be relevant, indexable, internally linked, canonicalized correctly, and present in clean sitemaps. A 301 to a weak or irrelevant page can still lose traffic.

What if I changed my WordPress permalink structure?

Treat it as a URL migration. Build a map from every old permalink to the new destination. Include category bases, trailing slash behavior, product bases, pagination, and old ?p=123 fallbacks if they resolve.

Can I delete the old host after the migration?

Only if redirects are handled somewhere else and tested. Many sites lose traffic because the old host was the only place redirects existed. Before decommissioning anything, crawl old URLs and confirm they still resolve correctly.

Conclusion: The repair playbook should have been the launch checklist

A WordPress migration recovery is not glamorous. It is URL accounting, redirect discipline, template checks, and patience. The same checklist that repairs the drop should have existed before launch.

At seojuice.com, the same rule applies. Boring URL continuity beats heroic cleanup. Use this article twice: once to repair the current migration, and once before the next one ships.

Need help finding the break?

If your WordPress migration dropped organic traffic and the cause is still unclear, start with the URL map and redirect audit. SEOJuice can help turn the panic into a repair queue, then into a launch checklist for the next migration.