Column 1

How to Fix WordPress 404 Errors and Redirects

WordPress 404 and redirect troubleshooting checklist for permalinks, link repairs, and customer-path testing

When a visitor sees a WordPress 404 page, the best fix depends on what changed. A single retired service page, every blog post, an old campaign link, and a site-wide permalink problem are different incidents. Start by identifying the affected URL pattern before changing a setting or adding a redirect.

Start With the Visitor Path

Open the reported address in a private browser window and note what happens. Check whether the problem affects one URL, a section such as posts or products, only an old domain, or ordinary navigation links. Prioritize pages that receive search traffic, referrals, advertisements, email clicks, orders, leads, or support requests.

A real missing page does not always need a redirect. Redirect an old URL only when there is a close, useful replacement for the visitor. Rebuilding the original page can be better when the information is still needed. Sending every missing URL to the home page hides useful context and makes it harder to see what actually needs repair.

Check WordPress Permalinks Carefully

For widespread WordPress 404 errors, go to Settings > Permalinks and confirm that the site is using the expected structure. WordPress documents that visiting this screen refreshes the rewrite rules; there is no reason to save the form merely to force a refresh. Use Save Changes only when the permalink setting itself needs to change.

Do not casually change a long-running site's permanent URL structure. If a structure change is intentional, treat it as a content move: map the old public URLs to their closest replacements, update internal links, and test the final destinations before promoting the new structure.

Give Each Redirect One Owner

Redirects may be managed by WordPress, a redirect plugin, a hosting control panel, or a CDN. Pick one primary owner for each class of redirect and document it. Competing redirects at several layers are a common cause of loops, unexpected destinations, and inconsistent results between cached and uncached visitors.

For a WordPress content move, manage the redirect where the content team can maintain it. For a domain-level or hosting-level move, cPanel's Domains > Redirects interface can be appropriate. Its documentation distinguishes permanent and temporary redirects, notes that an existing redirect must be removed and recreated to change it, and keeps HTTPS handling separate under Domains. Keep an inventory of intentional redirects so a future migration does not duplicate them.

Repair Links, Canonicals, and Discovery

After a permanent content move, update menus, body links, button links, and related-post links to point directly to the final page. Review the final page's canonical URL and make sure sitemap entries represent the public destination, not a retired route. The WordPress indexing and noindex guide helps confirm that the repaired page can be discovered, while the sitemap submission guide covers the next discovery step.

When the issue follows a hosting move, domain change, or SSL change, first verify that the public hostname is stable before changing more than one system. The WordPress migration, DNS, and email cutover checklist is a useful companion for that wider maintenance window.

Verify Before Calling It Fixed

Test the old public URL and confirm that the visitor reaches the intended final page.
Open the final page directly and confirm that it loads normally without a redirect loop.
Check representative customer paths, such as navigation, contact forms, checkout, login, or booking links.
Clear the relevant page cache and CDN cache after the change, then test again from a private browser window.
Review the canonical URL, sitemap entry, and internal links for a permanent content move.

When To Pause and Escalate

Pause when the issue affects all post types, ecommerce checkout, authentication, a domain migration, or more than one redirect layer. Capture the affected public URLs and the intended destinations, then make one controlled change at a time. That keeps a routine WordPress repair from turning into a confusing site-wide incident.