Identify whether a post is missing, a rewrite rule failed or a proxy and WordPress disagree about the requested path.
Recognize the symptoms before changing settings
The same visible error can originate in different layers. Your first objective is to identify whether the failure is specific to a route, a user action, a hosting component or a recent change. Do not treat a browser message as a complete diagnosis.
- Homepage loads while single posts or taxonomy pages return 404.
- Only a moved or deleted URL is missing.
- The failure began after a permalink, server or migration change.
Record the original URL, time of failure, browser or HTTP error and the last change that occurred before the issue began. These observations make later comparisons reliable, especially when caching or multiple servers are involved.
Before you change anything
If the site is taking payments or sending messages, confirm whether an operation may have already completed before resubmitting it. Make one isolated change at a time, then test the original failure again.
Diagnosis: find the layer that actually failed
Work through these plausible causes in evidence-first order. More than one can coexist, but fixing the first confirmed cause is safer than making several speculative adjustments.
Common underlying causes
- Content was deleted or slug changed.
- Rewrite rules were not refreshed after configuration changes.
- Apache AllowOverride or Nginx routing is wrong.
- An edge rule points an old URL to the wrong origin or path.
Three checks that narrow the problem
- Search the content list for the exact slug and publication status.
- Test the canonical permalink versus a plain-query URL on staging.
- Look for 404 responses generated by WordPress versus server/CDN branded error pages.
The relevant response, request log and configuration source together provide better evidence than a generic error screenshot. If you cannot access logs, gather the failing URL and timestamp and request the corresponding records from your hosting provider.
How to interpret conflicting results
If the first check points toward content was deleted or slug changed, focus on reproducing that condition without changing unrelated settings. A quick improvement after a targeted test is useful evidence but not yet proof that the root cause is removed.
If your second check suggests rewrite rules were not refreshed after configuration changes, collect the corresponding service or application log and compare what happens immediately before and after the failed request. This prevents mistaking correlation for cause.
If neither case fits, consider an edge rule points an old url to the wrong origin or path. Work from the outside in: DNS and connection, web server and proxy, PHP/WordPress runtime, then the affected plugin, theme or data. When a check gives inconclusive results, record that uncertainty instead of labelling it a confirmed fix.
Step-by-Step Troubleshooting
Choose the safest method for your access level. Use the Beginner tab for recovery and the Advanced tab for log-based diagnosis and targeted fixes.
Confirm the content and exact URL
Check Posts or Pages for the target slug, publication status and parent path. Watch for trailing slashes, capitalization and redirects to a non-existent destination.
Refresh WordPress rewrite rules safely
Open Settings → Permalinks and click Save Changes once. Retest the same URL without changing permalink format. This often refreshes WordPress rules but cannot repair incorrectly configured Nginx or restrictive hosting settings.
Redirect truly moved content
If the original page was deliberately moved, create a specific 301 from the old URL to its closest relevant replacement. Leave genuinely nonexistent URLs as 404 instead of routing everything to the homepage.
Inspect rewrite handling at the correct layer
For Apache, verify that the application rewrite configuration is permitted; for Nginx, have the host inspect the active location/try_files rules. Do not paste .htaccess syntax into Nginx.
# Nginx example for a standard WordPress setup; verify against your hostlocation / { try_files $uri $uri/ /index.php?$args;}Check canonical links and caches
Review redirect rules, multilingual plugins and caches if the site has multiple canonical URL formats. Revalidate the permalink after purging the affected cache key.
Audit related internal links
Use a crawler or WordPress link report to replace outdated internal URLs, then test sample posts, categories and search results.
How to verify the repair
Do not call a problem solved solely because one browser reload succeeds. Retest the exact workflow that failed, then include a normal public request and one administrator action. Keep the site cache and authenticated/anonymous behavior in mind.
- The intended page returns 200 at its canonical URL and old moved URLs redirect once.
- Unrelated missing pages continue to return an appropriate 404.
Complete the checklist below as you test. The progress indicator belongs to this article and is intended as a reading aid, not a guarantee of server health.
Solution Checklist
If it still fails: rollback and escalation
If the symptom remains, stop repeating the same changes. Save the newest error evidence and compare it with the pre-change state; the unchanged behavior is a useful clue that the current hypothesis was wrong.
- Restore the previous rewrite/server rules if new routes fail.
- Revert incorrectly broad redirects and retest the original request path.
When escalating to your provider or developer, send the time, affected URL, relevant status/log excerpt, environment version and the specific changes already tried. Remove passwords, session cookies, personal information and secret keys from the report.
How to prevent the error from returning
- Keep a permalink and redirect change log.
- Test internal links in staging before migrations.
After a successful fix, make a brief incident note: symptom, root cause, effective change, verification test and rollback instructions. This is much more useful than keeping a list of unverified tweaks.
Further reading: official documentation
This guide explains diagnostic choices rather than guaranteeing that one setting will work on every host. Verify the actual software versions, hosting environment and provider restrictions before applying examples.