Verify the exact public page and publication state first. Refresh the existing rewrite rules where appropriate, then correct the responsible server or plugin route while preserving the intended URL structure.
If your WordPress homepage loads but published articles return 404 errors, check the affected URL and the route that handles it before changing your permalink structure. Refreshing existing rewrite rules can help after certain changes; choosing a different public URL format is a separate migration and can create more broken links.
This guide separates a missing page from a routing fault, then gives you a narrow recovery process. It is based on official documentation checked on 13 October 2026. The examples are diagnostic illustrations, not results from testing your installation.
First establish what is actually missing
A 404 response means the requested resource was not found at that address. It does not identify the component responsible or prove that the WordPress database has lost a post. A theme can display a friendly error page, while a server or delivery layer can generate its own.
Copy the complete failing public URL. Check the domain, path, trailing punctuation and any accidental space. Compare it with the permalink shown for the same item in the editor. Do not use a private preview link as evidence that the normal public address works.
| Pattern | Useful next check |
|---|---|
| One old article URL fails; its current URL works | Look for a changed slug and a missing relevant redirect |
| Most published article paths fail but the homepage works | Inspect permalink routing and the web server configuration |
| Only one custom content type fails | Check the plugin or code that registers that type and its routes |
| The page works for an administrator only | Check publication status, access rules and logged-out behaviour |
| The HTML page works but an image or PDF returns 404 | Check that asset’s exact URL and file; do not assume post permalinks are responsible |
Check two or three representative URLs rather than relying on one bookmark. Record when the problem began and whether it followed a migration, plugin change, domain change or restoration. This small incident record makes later support much more specific.
Check publication status before repairing routes
In the correct site’s administration area, locate the post or page and inspect its status, visibility and permalink. WordPress distinguishes published, draft, pending, private, scheduled and trashed content; its post status documentation explains why an editor can have access that ordinary visitors do not.
If the content should still be private or scheduled, a public error may be expected. Do not publish a private customer page simply to remove a 404. If the item was intentionally removed, decide whether there is a genuinely equivalent replacement before setting up a redirect.
For a moved article, update internal links to its current address and preserve useful incoming links with an appropriate redirect. Our guide to changing WordPress permalinks covers that planned URL change. A rewrite refresh cannot recreate deleted writing, recover a missing upload or decide where an obsolete article should lead.
Refresh the existing rules without choosing a new structure
Before touching routing settings, record the currently selected permalink structure and category/tag bases. Confirm that you have a recovery route and are working in the intended installation, particularly when one hosting account contains several websites.
- Open Settings → Permalinks in that site’s WordPress administration area.
- Compare the displayed structure with the recorded intended structure. Leave it unchanged when your task is a routing repair.
- Read any configuration or file-write notice shown by WordPress.
- Recheck the same failing public URLs outside your administrator session.
- If the failure remains, investigate the responsible server or plugin layer rather than repeatedly changing settings.
The official Permalinks screen reference says that visiting this screen flushes rewrite rules. You do not have to switch to Plain and back merely to request a refresh. If you intentionally edit a setting, Save Changes is needed to save that edit.
WordPress’s rewrite function reference also warns that flushing is an expensive operation. Do not paste a snippet that runs a flush on every visitor request. If a plugin loses its routes repeatedly, fix when it registers them or involve its maintainer; repeated flushing can hide the symptom without correcting the cause.
Know whether Apache, Nginx or a managed layer owns the routing
On an Apache installation, WordPress may need appropriate rewrite rules in its .htaccess file. A warning about being unable to update that file is evidence to investigate, not permission to replace the entire file with a snippet found online. It may also contain security controls, redirects or hosting-specific rules.
Use a supported file editor only after confirming the exact document root and preserving the current file. Ask the host to check the site’s required rewrite support and permissions if you cannot establish the correct configuration. Do not make broad permission changes such as granting every account write access.
Standalone Nginx does not use Apache’s .htaccess mechanism. Its routing is server configuration managed by an administrator. The WordPress Nginx handbook also notes that Nginx can sit in front of Apache, so a response header alone does not reveal the complete arrangement. Ask which layer routes this domain to WordPress. Adding an Apache file to a standalone Nginx site will not configure its routes.
A subdirectory installation or WordPress Multisite can need different rules from a single site installed at the domain root. Give the host the real installation layout; do not copy a root-installation example over a network configuration.
Separate a plugin route from an ordinary article
If normal articles work but a directory, course, shop or other plugin-created section fails, record that distinction. Check whether the responsible plugin is installed and active and whether the failure started after its update or configuration change. A route whose owner is missing cannot necessarily be repaired by refreshing ordinary post rules.
Use a staging copy when reproducing a conflict, especially if the plugin manages customer access or transactions. Change one relevant variable at a time and keep a record of the old and new result. Do not deactivate every production plugin when the evidence points to one route family.
If PHP errors accompany the failed requests, use private host logs or a controlled debugging setup. The WordPress debugging guide distinguishes logging from displaying errors. Public stack traces and log files can expose information that readers do not need.
Check caching after the underlying route is corrected
Retest the original URL after the repair, then use the site’s supported cache controls for that affected page if an old response remains. A private window removes some browser-session differences but does not guarantee that a server or CDN cache is bypassed.
Compare the affected URL with a known working page using the browser’s Network panel or a host-provided diagnostic. Record the response status and any redirect destination, not only the appearance of the page. An attractive error template can still return the wrong status.
For example, suppose /guides/email-setup/ was deliberately moved to /guides/business-email/. The old URL should lead to the relevant replacement, and the replacement should load successfully without a loop. Redirecting every unknown URL to the homepage leaves readers without the answer they requested.
Handle genuine missing pages honestly
A page with no replacement can return a useful 404 with navigation and search. Google explains that genuine missing URLs and error pages returning successful status codes are different cases in its HTTP status guidance. Do not change an error to HTTP 200 simply to make an audit look green.
For content that really moved, Google’s redirect guidance distinguishes permanent and temporary moves. Choose the behaviour that matches the move, and update the sitemap and internal links where applicable. A successful redirect is not a guarantee of preserved rankings.
Finish with a small acceptance record
- The original failing URL now has the intended result: useful content, a relevant redirect or a genuine missing-page response.
- Several existing articles, a category/archive and the homepage still work logged out.
- Any affected plugin-created route works in its ordinary visitor workflow.
- The public permalink structure remains the intended one.
- No new redirect loop or public debug output has appeared.
If you need help, send the maintainer the affected public URLs, approximate failure time with time zone, recent change, observed status and checks already completed. Keep login credentials, recovery links and private server logs out of public support posts. That gives them a concrete routing problem to investigate instead of another unexplained request to “reset permalinks.”
Sources and verification
Editorial review 2026-10-13. Source check dates are recorded separately. Notes describe what each source supports and its limits.
View sources
- MDN: 404 Not FoundChecked Meaning of a missing-resource response.
Limits: Status alone does not diagnose the application or establish whether content was deleted. - WordPress: Post StatusChecked Published, draft, pending, private, future and trash states differ.
Limits: Public visibility is checked separately from editor access; no publication of private content is recommended. - WordPress: Settings Permalinks screenChecked Visiting the settings screen flushes rules; saving changes persists setting edits; configuration notices require attention.
Limits: No need to alternate URL structures for a refresh and no blanket replacement of an existing configuration file. - WordPress: flush_rewrite_rules()Checked Rewrite flushing is an expensive operation and distinguishes rewrite state from content.
Limits: No per-request flush code or claim that refreshing recreates deleted data. - WordPress: Nginx administration handbookChecked Standalone Nginx has server-level configuration rather than Apache .htaccess; Nginx may also proxy Apache.
Limits: No generic server configuration is supplied; site layout and actual stack must be identified. - WordPress: Debugging in WordPressChecked Controlled debugging, backup/staging preparation and separate logging/public display concerns.
Limits: No production debug snippet, public log publication or claim that one successful request verifies a site. - Google: How HTTP status codes affect crawlersChecked Missing pages, soft errors and persistent server failures have distinct crawling/indexing implications.
Limits: No ranking preservation promise, fixed recovery time or instruction to mask failures with HTTP 200. - Google Search Central: Redirects and Google SearchChecked Permanent and temporary redirects should reflect the real move.
Limits: No blanket homepage redirect or guarantee of preserved ranking.