WordPress Redirects, Broken Links and URL Migrations: What to Fix and How to Verify It

The short version: redirect, repair or return 404?

Redirects, broken links and URL migrations are related, but they are not the same problem. A broken link is a link that sends a user or crawler to a URL that no longer provides the expected resource. A redirect is an HTTP response that sends the request to another URL. A URL migration is a planned change in which many existing URLs move to new locations, such as a domain change, an HTTP-to-HTTPS move or a permalink restructure.

The practical decision is simple:

• The content has permanently moved: use a permanent server-side redirect, normally 301 or 308, to the closest equivalent new URL.
• The move is genuinely temporary: use a temporary redirect such as 302 or 307 so the original URL remains the intended long-term location.
• The content is gone and there is no relevant replacement: return 404 or 410 and remove or update internal links that still point to it.
• The URL should still work: fix the page or link instead of hiding the fault behind a redirect.

Google's current redirect documentation recommends permanent server-side redirects when a page has permanently moved. It treats 301 and 308 as permanent redirects and 302 and 307 as temporary redirects. The important distinction is the intended permanence of the move, not a belief that one status code transfers a fixed percentage of “SEO value”.

A 404 is not automatically an SEO problem

A 404 response means the requested resource was not found. That is the correct result when a page has genuinely disappeared and there is no suitable replacement. The SEO problem is usually the reason people or crawlers keep reaching that URL: an outdated internal link, a faulty migration rule, a mistyped URL in navigation, an old sitemap entry or an external link to content that no longer exists.

Do not automatically redirect every missing URL to the homepage. When an old page has no close replacement, a relevant custom 404 page with useful navigation is better for users than an unrelated redirect. Google also warns that large numbers of irrelevant redirects to a single destination can be treated as soft 404s during a site move.

For internal broken links, repair the source link wherever you control it. That removes an unnecessary step for users and avoids making your own site depend on redirects forever. If you need a broader repair workflow, see ScanMySEO's broken links guide.

Why redirects and broken links matter

The strongest reasons to fix these issues are practical. Broken internal links interrupt user journeys, can make important pages harder to discover through your site's link structure, and create avoidable maintenance debt. Incorrect redirects can send people to the wrong page, create loops, add delay or prevent a migration from being interpreted as intended.

Permanent redirects also act as a canonicalisation signal. Google states that 301 and other permanent redirects do not cause a loss in PageRank during a site move. That does not make every redirect harmless: the destination still needs to be relevant and accessible, and conflicting signals such as old internal links, old canonicals, blocked pages or redirect chains can make a migration harder to process.

Crawl budget needs proportion. For most SME WordPress sites, it should not be the primary reason to fix a few broken links. Google's crawl-budget guidance is aimed mainly at very large, rapidly changing sites or sites with substantial “Discovered - currently not indexed” inventory. Long redirect chains and large volumes of unnecessary URLs can make crawling less efficient, but a small business site should normally prioritise user journeys, accurate internal linking and clean migration signals first.

Diagnostic workflow: find the failure before choosing the fix

A useful audit separates where the bad URL is referenced from what the bad URL currently returns. That distinction prevents the common mistake of adding a redirect when the actual fix is to change a link.

1. Crawl your own internal links. Find internal links that resolve to 4xx errors, 5xx errors, redirects or unexpected destinations. Check navigation, footer links, breadcrumbs, body links, image links and other repeated components as well as ordinary page copy.
2. Inspect the response path. Record the starting URL, every redirect hop, the final URL and the final HTTP status. A healthy permanent move normally looks like old URL → 301/308 → final URL → 200.
3. Classify why the old URL exists. Was the page renamed, deleted, merged, temporarily moved, mistyped, or changed during a permalink or domain migration? The cause determines the fix.
4. Check whether a true replacement exists. Match by user intent and content, not merely by category. A retired service page should not be redirected to the homepage just because both belong to the same business.
5. Prioritise the URLs that matter most. Start with broken links in navigation and templates, URLs that receive meaningful traffic, pages with valuable external links, conversion pages and migration URLs that should have a one-to-one destination.

If you are troubleshooting a single URL, a browser's developer tools, an HTTP header checker or a crawler can show the response chain. For a site migration, use a URL mapping spreadsheet or export so every old URL has an explicit intended outcome before redirects are switched on.

Choose the response by what happened to the content

The table below is a decision aid, not a rule that every historical URL deserves a redirect.

Do not use noindex as a substitute for a redirect. A redirect changes where the request goes; noindex tells a search engine not to index the page it successfully reached. They solve different problems.

A safer WordPress URL-migration workflow

WordPress migrations have two layers: the public URL mapping search engines and users see, and the WordPress/database configuration that may still contain old addresses. Treat both as part of the project.

1. Back up before changing URLs. Keep a restorable copy of the database and files. WordPress's official migration handbook recommends backing up before moving the site and notes that URL changes can leave references to the old location in the database.
2. Build the old-to-new URL map. Combine the old XML sitemap, a crawl of the live site, important URLs from Search Console/analytics, and any other known landing pages. Decide whether each old URL maps to a new URL, remains unchanged, or should end in 404/410.
3. Prepare the new WordPress location. When the domain or path changes, confirm the WordPress Address and Site Address are correct. Review permalink/rewrite configuration, menus, media URLs and other places where an old absolute URL may have been stored.
4. Update stored URLs safely. Avoid blind database-wide text replacement: serialized WordPress data can be damaged by careless replacements. If WP-CLI is available, its search-replace command understands serialized data and supports a dry run. Back up first and have a developer or host handle this step if you are not comfortable working at database level.
5. Implement direct permanent redirects. Use your host, server configuration, CDN or WordPress redirect mechanism to send each old URL directly to its final relevant destination. Server-side 301/308 redirects are Google's preferred approach when technically possible.
6. Update the new site's own signals. Change internal links to the new URLs, make the new pages' canonical URLs point to the correct new locations, update hreflang annotations where used, and publish sitemaps containing the new canonical URLs.
7. Remove staging restrictions at launch. A migration can fail if a temporary noindex directive or robots.txt block survives on the production site.

Google's site-move guidance recommends mapping old URLs to new URLs, updating internal links, using permanent server-side redirects where possible and testing the move carefully. For domain or subdomain migrations, use Search Console's Change of Address process; Google says it is not required for HTTP-to-HTTPS changes, www/non-www switches on the same domain, or path-only changes.

Point old URLs straight to the final destination

A migration often inherits historical redirects. For example, an old page may already redirect from /services-old/ to /services/; a new redesign then moves /services/ to /what-we-do/. If you simply add another rule, the first URL now takes two hops.

Where you control the rules, update the oldest redirect so it points directly to the current final URL. Google recommends avoiding redirect chains and directing requests to the final destination where possible. This also reduces delay and makes troubleshooting easier. For a deeper diagnostic workflow, see the ScanMySEO guide to redirect chains.

Do not design around the maximum number of hops a crawler might tolerate. The cleaner objective is one deliberate redirect from the old location to the current final location.

Verification: prove the migration works instead of assuming it does

A redirect is not verified because the destination page looks correct in a browser. Browsers can hide intermediate hops, cache redirects and make a faulty chain appear smoother than it really is. Test the HTTP behaviour and then test the site's signals around it.

• Old moved URL: confirm it returns the intended permanent redirect, usually 301 or 308.
• Redirect target: follow the redirect and confirm the final target returns 200. The old URL itself should not return 200 if it is meant to redirect.
• Deleted URL with no replacement: confirm it returns 404 or 410, not a branded error page served with a 200 status.
• Internal links: crawl the new site and make sure your own links point directly to final URLs rather than relying on redirects.
• Canonical tags: check that new pages reference the intended new canonical URLs.
• Sitemaps: make sure current sitemaps contain the new canonical URLs rather than old redirecting URLs.
• Indexing controls: confirm production pages are not accidentally blocked by noindex or robots.txt rules carried over from staging.
• Search Console: verify the relevant properties, submit the new sitemap, inspect representative URLs and monitor Page Indexing plus search performance while Google processes the change.

Temporary ranking and indexing fluctuations can happen during a significant site move while Google recrawls and processes old and new URLs. Success is not “all metrics improve immediately”; it is that old URLs consistently resolve to the intended outcomes, new URLs are accessible and internally linked, and the old-to-new transition is visible in crawling, indexing and traffic data.

What to fix first when the list is large

If an audit returns hundreds or thousands of redirect and broken-link findings, do not treat every row as equally urgent. A sensible order for an SME WordPress site is:

1. Sitewide navigation and template faults: one broken menu or footer link can affect many pages and users.
2. Migration-critical URLs: important landing pages, revenue or lead-generation pages, URLs with external links, and pages receiving meaningful search traffic.
3. Redirect loops and dead-end redirects: these prevent users from reaching the intended content at all.
4. Long or repeated redirect chains: especially where your own internal links still point to the first URL in the chain.
5. Low-value historical 404s: fix internal references if they exist, but do not manufacture irrelevant redirects merely to make a 404 count reach zero.

This priority order separates a real user or migration risk from a technically valid historical 404. The goal is not a dashboard with no 4xx responses; it is a site where current links work, moved content has accurate destinations and retired content returns an honest status.

Common mistakes that create avoidable migration problems

• Redirecting every retired URL to the homepage. Use the closest relevant replacement or let the URL return 404/410.
• Leaving old URLs in menus and page content. Redirects are a safety net, not a reason to preserve outdated internal links.
• Changing domain, CMS, design and URL structure in one launch. When feasible, separating major changes makes failures easier to diagnose; Google also recommends changing one major thing at a time during site moves.
• Forgetting WordPress-stored URLs. Menus, media references, plugin data and database values can keep pointing to the old domain or path after the visible pages appear to work.
• Removing redirects too soon. Google's site-move documentation recommends keeping them for as long as possible, generally at least a year, and users may benefit from keeping important redirects indefinitely.
• Judging success only by the absence of 404s. A legitimate 404 is better than an irrelevant redirect that misleads users and search engines.

Final checklist

• Every permanently moved important URL has a relevant final destination.
• Permanent moves use 301/308 where appropriate; temporary moves are not mislabeled as permanent.
• Deleted content with no replacement returns 404/410.
• Internal links point directly to final URLs.
• Redirect chains and loops have been removed where practical.
• WordPress Address, Site Address, permalink/rewrite settings and stored absolute URLs have been reviewed when the domain or path changed.
• Canonical URLs, hreflang annotations where relevant and XML sitemaps use the new URLs.
• Production pages are not accidentally blocked by staging robots/noindex rules.
• Representative old and new URLs have been tested at HTTP level.
• Search Console and analytics are being monitored after the move rather than assuming launch day is the end of the project.

For WordPress owners, the most useful rule is to match the technical response to what actually happened to the content. Redirect genuine moves, repair links you control, let genuinely retired content return an honest not-found response, and verify the complete path after any URL change.