SEO made simple: WordPress redirects, broken links and URL migrations

The simple rule: fix the link, redirect the move, or return an error

Redirects, broken links and URL migrations are related, but they are not the same problem. Treating every old URL as something that needs a 301 redirect can create just as much confusion as leaving genuine moves unredirected.

For most WordPress sites, the practical decision is:

• The page still exists at the same URL, but a link is wrong: correct the link.
• The content has permanently moved to a new URL: point internal links at the new URL and add a permanent server-side redirect from the old URL to the most relevant new one.
• The move is temporary: use a temporary redirect.
• The content is gone and there is no useful replacement: return a genuine 404 Not Found or 410 Gone response instead of redirecting the visitor somewhere unrelated.

Google currently treats 301 and 308 as permanent redirects and 302 and 307 as temporary redirects. For a permanent page move, Google recommends a server-side permanent redirect where possible. See Google's redirect guidance.

What redirects, broken links and URL migrations actually mean

A redirect is an HTTP response or other forwarding mechanism that sends a request from one URL to another. For SEO-sensitive URL changes, server-side redirects are usually the clearest option because browsers and crawlers receive the redirect before the page content is rendered.

A broken link is a link whose destination does not work as intended. An internal link might point to a URL returning 404, to a page that now redirects elsewhere, or to a malformed URL. The best fix is usually to change the source link so it points directly to the final working page. If the old URL also has external links or may still be visited, it can still need a redirect as a separate issue.

A URL migration is a planned change from old URLs to new URLs. It might involve a single WordPress page slug, a whole permalink structure, a section of the site, HTTP to HTTPS, or a domain change. The core migration job is to map each old URL to its appropriate new destination, update the site to use the new URLs, and then redirect old URLs that have a genuine replacement.

A redirect chain is a sequence such as A → B → C. A redirect loop is different: it sends a request in a cycle, such as A → B → A, so the destination is never reached. If you need help separating chains from loops and deciding which ones matter, see ScanMySEO's redirect chains guide.

Diagnostic checklist: find the problem before changing redirects

Do not start by adding redirect rules. First identify the old URL, the current response, the intended destination, and whether the content still exists.

Step 1: crawl your internal links

Start with a crawl or link check of your WordPress site. Look for:

• internal links that return 4xx errors;
• internal links that unnecessarily pass through one or more redirects;
• redirects that point to another redirect instead of the final page;
• redirect loops;
• links to URLs you changed recently.

For a broken internal link, update the link at its source rather than relying on a redirect forever. Redirects are useful safety nets for old URLs; they should not become the default internal navigation path. For a fuller repair workflow, use the broken links guide.

Step 2: use Search Console for indexing evidence, not as a redirect-chain tracer

Google Search Console is useful for understanding how Google knows about a specific URL and for monitoring indexing after a migration. The URL Inspection tool can show indexed information for a URL and can run a live fetch.

There is an important limitation: Google's live URL test follows redirects before testing the destination, but it does not tell you that it followed a redirect or show the final redirected URL. That means it is not a reliable tool for tracing a multi-hop redirect path. Use an HTTP checker, crawler, browser developer tools, server logs, or your hosting platform's redirect tester for that job. Use Search Console to investigate indexing and migration outcomes instead. See the URL Inspection documentation.

Step 3: trace the full redirect path

Test the old URL and record each HTTP response until you reach the final destination. The ideal permanent move is normally one direct hop:

old URL → 301 or 308 → final URL returning 200

Fix cases where an old URL travels through historical intermediate URLs. Google can follow redirect chains, but its migration guidance recommends redirecting directly to the final destination where possible because chains add latency and complexity.

Also check whether multiple redirect systems are active at once. On WordPress, redirects may be created by a plugin, your hosting control panel, Apache or Nginx configuration, a CDN, or custom application code. Overlapping rules are a common cause of loops and unexpected destinations.

Choose the fix from the URL's real state

The table below is a decision aid, not a rule that every old URL must be redirected.

Fixing broken links

For an internal broken link, find the page containing the link and change its href to the correct destination. If the destination no longer exists, decide whether the link should be removed or replaced with a genuinely useful alternative.

Do not redirect every missing page to the home page. Google's site-move guidance warns against redirecting many old URLs to one irrelevant destination because this can confuse users and may be treated as a soft 404.

Implementing redirects for WordPress URL changes

WordPress lets you edit individual slugs and change broader permalink structures. Its own documentation describes permalinks as URLs that should remain stable, which is a useful reminder: changing an established structure can affect many pages at once. Review the WordPress permalink settings documentation before changing a site-wide structure.

For a live site, use this order:

1. Record the old URLs first. For a one-page slug edit this may be a single pair. For a structure change, export or crawl the current URLs so you have a complete mapping.
2. Choose the new URL deliberately. Avoid changing a URL twice because the first replacement looked imperfect.
3. Set the permanent redirect at the most reliable layer you control. Depending on the site, that may be the hosting platform, web server, CDN, redirect plugin, or custom code. Google recommends server-side permanent redirects where possible.
4. Update WordPress links to use the destination directly. Change menus, body links, buttons, breadcrumbs, templates, and other internal references that still use the old URL.
5. Update canonical URLs and sitemaps. The new page should normally self-canonicalise, and XML sitemaps should contain the new URLs rather than old redirecting URLs.
6. Test before assuming it worked. Confirm the old URL returns the expected redirect and the final destination returns the intended successful response.

A safer WordPress URL migration workflow

Changing a single slug and migrating thousands of URLs use the same principles, but the larger the change, the more important the planning becomes. Google's current site-move guidance recommends creating an old-to-new URL mapping, using permanent redirects, updating internal links and canonical annotations, updating sitemaps, and monitoring the move.

Before changing URLs

• Create an old-to-new URL map, starting with important pages and any URL that receives traffic or external links.
• Make sure each proposed destination exists and is genuinely relevant to the old page.
• Check that the new page can be crawled and is not accidentally blocked by robots.txt or a noindex directive.
• Back up the site and, for larger changes, test the redirect rules in staging or another safe environment where possible.
• Avoid combining a major URL migration with unrelated redesign, CMS, and content changes unless there is a strong operational reason. Fewer simultaneous variables make problems easier to diagnose.

When launching the migration

• Redirect each old URL directly to its final new equivalent.
• Do not send unrelated old pages to the home page just to eliminate 404s.
• Replace old URLs in internal links instead of making users pass through redirects.
• Update the new page's canonical URL and any hreflang references if they exist.
• Update and submit the sitemap containing the new URLs.
• For a genuine domain or subdomain move, review Google's Change of Address process. It is not required for ordinary path changes within the same domain.

Google recommends keeping migration redirects for as long as possible and generally for at least one year. From a user perspective, keeping stable old URLs redirected for longer can still be useful when bookmarks and external links remain in circulation.

Do not make “crawl budget” the main reason to fix every broken link

Broken links should be fixed because they create dead ends, weaken navigation, and can obscure your intended site structure. But for a typical small or medium WordPress site, it is usually misleading to present every 404 as a serious crawl-budget problem.

Google's current crawl-budget guidance is aimed primarily at very large sites, rapidly changing sites, or sites with substantial numbers of discovered-but-not-indexed URLs. Google also explicitly recommends real 404 or 410 responses for permanently removed URLs. On an SME site, prioritise accurate responses, clean internal links and a coherent URL structure before worrying about crawl-budget optimisation.

WordPress redirect troubleshooting

New WordPress URLs return 404

First confirm the slug or permalink setting is what you intended. WordPress notes that its permalink system depends on the server environment and rewrite configuration. If pretty permalinks fail after a change, review Settings → Permalinks and your host's rewrite setup rather than immediately adding more redirect rules. On Apache, .htaccess permissions or rewrite configuration may be involved; other hosts may use Nginx, LiteSpeed, or managed routing instead.

The old URL redirects to the wrong page

Look for competing redirect layers. A plugin rule may be overridden by a host-level rule, CDN rule, web-server configuration, or custom code. Test the old URL while temporarily isolating the redirect source where safe, then keep one clear authoritative rule.

The browser reports too many redirects

A loop often comes from two rules undoing each other—for example, one system forces a URL variant that another system immediately changes back. Trace the response sequence and fix the first conflicting rule rather than stacking another redirect on top.

The old URL still appears in Google

That can be normal shortly after a migration. Google processes URL moves over time and on a per-URL basis. Check that the redirect is permanent, the destination is indexable, internal links and the sitemap use the new URL, and then monitor the change rather than repeatedly changing the setup.

Verification protocol: prove the change worked

A redirect is not finished when the rule is saved. Verify the whole path and the signals around it.

1. Test the old URL. Confirm it returns the expected permanent or temporary status and points to the intended destination.
2. Test the final URL. Confirm it loads successfully and is the page you actually intended users to reach.
3. Crawl the site again. Internal links should point directly to final 200 URLs rather than relying on redirect hops.
4. Check for chains and loops. Historical redirects should not force visitors through avoidable intermediate URLs.
5. Check canonical and sitemap consistency. The destination should normally reference itself as canonical, and the sitemap should list the new URL.
6. Use Search Console to monitor indexing. Inspect important URLs and watch the Page Indexing and Sitemaps reports for unexpected errors or old URLs that are not transitioning as expected.
7. Monitor traffic and errors after a larger move. Analytics and server logs can reveal old URLs that were missed from the mapping or destinations that are failing under real traffic.

The goal is not to eliminate every 404 or create a redirect for every historical URL. It is to make each response truthful: working pages return successfully, permanent moves redirect to a relevant replacement, temporary moves stay temporary, and genuinely removed content clearly returns an error.