When the home page, admin and index.php?p=42work but the friendly URL for the same post returns 404, WordPress itself is probably available. The missing link is usually the rewrite path between Apache and the application.
Check the generated WordPress block, its location and the server policy that allows it to run before changing content or restoring the database.
What it means
Pretty permalinks rely on rewrite rules that pass requests for non-file paths to index.php. On Apache, WordPress commonly stores those rules in .htaccess.
A 404 can come from the server before WordPress runs or from WordPress after an incorrect base path. Comparing a query-style control with the friendly URL helps identify that boundary.
A realistic WordPress example
A site is moved from the web root into a subdirectory. Posts open through their numeric query URLs, but the copied .htaccessstill uses the old base and every pretty permalink fails.
After confirming the new document root, the administrator regenerates the WordPress block for the deployed path and verifies that Apache allows rewrite overrides there.
Why it matters and when to use it
The distinction prevents unnecessary database repairs and content edits. If the control URL loads the post, the content and basic WordPress routing are already present.
Use this diagnosis for broad friendly-URL failures. A single missing post may instead be a slug, status or content problem.
A straightforward route for beginners
- Test the home page, admin and a known post through a query-style URL.
- Confirm the public document root and WordPress installation directory.
- Save the complete active
.htaccessfile. - Open Settings, Permalinks and save the current structure to regenerate the WordPress block.
- Compare the generated base and target with the actual site path.
- Test posts, pages, archives, files and a genuinely missing URL.
The advanced route
Verify mod_rewrite, AllowOverrideand directory inheritance. If Apache ignores a valid file, inspect its virtual-host policy and error log rather than repeatedly rewriting the same block.
Separate a server 404 from the WordPress template response using headers and logs. Nested installations may have more than one .htaccess, so prove which directory handles the request.
Risks, common mistakes, backup, and rollback
Replacing the whole file can remove security and redirect rules, while rules for the wrong base can route every request incorrectly. File and directory exclusions must remain intact so assets are not sent unnecessarily through WordPress.
Keep the original file and metadata. If the regenerated block changes unrelated behavior, restore it and address the server policy or installation path directly.
How AIOWS helps:
AIOWS Htaccess Editor
AIOWS Htaccess Editor can help review the supported file and maintain the WordPress-side rewrite block without losing sight of custom directives around it.
Confirm the document root and save an external copy before editing. After regeneration, verify both pretty permalinks and controls such as existing files and unknown URLs.
The editor cannot enable mod_rewrite, change Apache AllowOverridepolicy or make Nginx use the file. Escalate those server conditions to the host or system administrator.
Related AIOWS articles
- WordPress .htaccess File: Complete Beginner's Guide
- How to Regenerate the Default WordPress .htaccess File
- How to Redirect an Old WordPress Slug After Changing a URL
Conclusion and recommended route
Use a working query-style URL to confirm WordPress, then repair the rewrite block and server support for the actual installation path. Preserve custom directives and verify more than one permalink type.
