Free tools Windows power users keep installed
One-click scans. No signup required.
If WordPress posts or pages suddenly return a 404 error, open Settings > Permalinks and click Save Changes without changing the structure. Visiting that screen flushes WordPress rewrite rules; on Apache, saving also regenerates the site’s .htaccess rules. If that does not restore the URLs, the next checks are the file contents and permissions, Apache’s rewrite configuration, or the Nginx server block.
Antihost offers managed WordPress hosting with free migration, one-click staging and a 14-day free trial.
What a broken permalink looks like
A permalink is the permanent URL WordPress builds for a post, page, category, tag, or custom post type. A permalink problem usually appears as a WordPress 404 error: the homepage opens, but an individual post, page, or archive says it cannot be found. In other cases every “pretty” URL fails while the homepage still works.
As an Amazon Associate I earn from qualifying purchases.
Recommended Free Tools
The WordPress record may still exist in the dashboard. The failure is often in the rewrite rules that translate a friendly path such as /news/example-post/ into the internal WordPress request. The quickest repair is to flush those rules from the Permalinks screen. Server-specific checks are needed when WordPress cannot write its rewrite file or when the web server is not Apache.
Use this order of operations
- Confirm the problem by opening one affected post or page in a private browser window.
- Go to Settings > Permalinks and click Save Changes without editing the selected structure.
- Read the message shown after saving. It tells you whether WordPress wrote the rules or wants you to copy them manually.
- If a manual update is requested, back up the existing
.htaccessfile, then paste the displayed rules in the correct location. - Check the file’s permissions and ownership, and confirm that the site is running on Apache or Nginx as you expect.
- Test a post, a page, an archive, and the homepage before making additional changes.
Step 1: Re-save the permalink settings
Open the correct screen
Sign in as an administrator and select Settings in the left-hand WordPress menu, then choose Permalinks. You do not need to change the radio button or enter a new structure for this repair. Loading the screen causes WordPress to rebuild its in-memory rewrite rules, and clicking the button commits the flush.
#1 Best Overall
Save without changing the structure
Click Save Changes. On an Apache installation, WordPress also attempts to write the rules it needs to .htaccess. Wait for the result before closing the tab, then open an affected URL again. Clear any page-cache or CDN cache only after confirming that the URL still fails; a cached 404 can otherwise make a successful repair look unsuccessful.
Understand the result message
WordPress documentation describes two outcomes. When it can write the file, the screen reports that the permalink structure was updated. When it cannot, it tells you to update .htaccess and displays the required rules in a text box near the bottom of the page. The exact wording can vary with the WordPress version, so use the message and the rules actually shown on your screen rather than copying a generic block from another site.
Step 2: Apply the displayed .htaccess rules safely
Back up before editing
A syntax error in .htaccess can take the entire site offline with a server error, not merely produce a 404. Download the current file through your host’s file manager or SFTP before changing it. Keep the backup outside the public web directory and record the original filename so you can restore it quickly.
Find the file
For a standard single-site installation, .htaccess is in the WordPress document root—the same directory that contains wp-admin, wp-content, and wp-includes. File managers often hide names beginning with a dot; enable “show hidden files.” If WordPress is installed in a subdirectory, use that installation’s document root, not necessarily the hosting account’s top-level folder.
Paste rules in the permitted location
Copy the rules WordPress displays, preserving every line. The WordPress Codex guidance places manually entered rules either before the line # BEGIN WordPress or after the line # END WordPress. Do not insert custom lines inside the generated block: a later permalink save can replace that section.
Save the file as plain text named exactly .htaccess. Do not let a text editor append .txt, and do not create a second file such as .htaccess.txt. Visit the homepage first; if it produces a server error, restore the backup immediately and ask the host to inspect the configuration.
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Fix the driver behind crashes, sound loss and screen glitches3Repair Windows errors before they cause bigger problemsStep 3: Check permissions and ownership
WordPress must be able to write the file when it regenerates rules. At the same time, an overly open mode can expose configuration details or permit unwanted edits. Official WordPress guidance lists 660 or 644 for .htaccess, depending on the server’s user and group setup.
| Check | What to verify | Why it matters |
|---|---|---|
| File exists | A real .htaccess is present in the WordPress document root. |
Apache cannot read rewrite directives from a file that is missing or stored in the wrong directory. |
| Mode | Use 660 or 644 as appropriate for the host. |
The web-server account needs the required access without granting broader access than necessary. |
| Owner and group | The file belongs to the account or web-server group your host expects. | A numerically correct mode can still fail if the process does not own the file or belong to its group. |
| Directory access | The document-root directory allows the server to traverse and read it. | Directory restrictions can prevent Apache from using an otherwise correct file. |
Change permissions in your host’s file manager, SFTP client, or shell only if you understand that account’s ownership model. If changing to 660 or 644 makes the site inaccessible, restore the previous mode and have the host set the correct owner and group rather than repeatedly guessing.
Step 4: Confirm the web server is configured for pretty permalinks
Apache: mod_rewrite and .htaccess
Pretty permalinks on Apache require the mod_rewrite module and an .htaccess file containing the WordPress rules. WordPress also needs write access when it is expected to update that file automatically. A successful save in the dashboard cannot enable a disabled Apache module or override a host policy that prevents directory-level overrides.
If the file contains the rules but every post and page still returns 404, send the host the exact symptom, the site’s document-root path, and the time of your test. Ask whether mod_rewrite is enabled and whether the virtual-host configuration permits the WordPress directory to use its .htaccess. Hosts may use different names and policies for that permission, so they must confirm the active server configuration.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Nginx: no .htaccess regeneration
Nginx does not use Apache’s .htaccess mechanism. Saving the Permalinks screen still flushes WordPress’s rewrite rules, but it cannot create or update an Nginx server configuration. The rewrite directives must be present in the site’s Nginx server block, which is normally managed by the host or system administrator.
Do not upload an Apache .htaccess file to an Nginx-only site expecting it to fix the 404. Contact the person who controls the Nginx configuration and provide the affected URL, the WordPress installation path, and confirmation that the homepage responds while pretty URLs fail. After the server block is corrected and reloaded, test the same URLs again.
Rank #4
| Environment | Where rewrite rules live | Who normally changes them |
|---|---|---|
| Apache | .htaccess in the WordPress document root, with mod_rewrite enabled. |
WordPress can regenerate the file when permitted; the host controls the module and directory policy. |
| Nginx | The site’s Nginx server-block configuration. | The hosting provider or server administrator; Nginx does not read .htaccess. |
When a plugin caused the 404s
Plugins that register custom post types or rewrite endpoints add new URL rules. If the errors began immediately after activating such a plugin, flush the permalinks after activation: open Settings > Permalinks and click Save Changes. This is especially important when the plugin’s own setup instructions say it creates a custom post type.
Test the plugin’s archive and one item URL separately from ordinary posts and pages. If only the new type fails, review its registered rewrite slug, whether its archive is enabled, and whether another plugin uses the same slug. Those settings are plugin-specific; do not edit generated WordPress rules blindly. Deactivate the new plugin only as a diagnostic step, and reactivate it after recording any setting that must be restored.
Diagnose by the pattern of failures
Only the homepage loads
This pattern indicates that the web server is serving the front page but is not handing friendly paths to WordPress. On Apache, check the presence of mod_rewrite, the location and readability of .htaccess, and the host’s directory-override policy. The rewrite-module requirement is established; the exact override setting varies by server and must be confirmed by the host. On Nginx, inspect the server block instead of looking for .htaccess.
Only one post or page is broken
A single failing URL usually points away from a site-wide rewrite failure. Check the item’s current slug in the editor, whether the content was moved to the trash or deleted, and whether a redirect is needed from an old slug. Compare the URL shown in the editor’s “View” link with the address you are testing. If the current URL works but an old one does not, the rewrite system may be healthy and the missing piece is a redirect or a corrected link elsewhere.
Errors began after editing the file
Restore the backed-up .htaccess immediately if the homepage or admin area now shows a server error. Then ask the host to validate the Apache configuration and reapply the exact rules generated by your Permalinks screen. Do not keep adding snippets from unrelated tutorials; directives written for a different directory layout, PHP handler, or server can make the outage worse.
The file keeps reverting or cannot be saved
Repeated failure to save generally means WordPress lacks write access, the file is owned by another account, or the host prevents application-level edits. Use the manual rules displayed by WordPress, correct the owner or permissions with the host’s help, and ask whether a security layer is restoring the file. On Nginx, a “reverting” .htaccess is not the relevant control because Nginx ignores it.
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Resetting a damaged file
If the existing Apache file is malformed and you have a backup, a common recovery procedure is to download the file, rename the server copy (for example, to .htaccess-old), and then return to Settings > Permalinks and save again so WordPress can generate a clean block. This procedure is vendor-guide advice rather than a guarantee: some hosts manage the file centrally or prohibit renaming it. Keep the backup, and stop if renaming produces a server error or you are unsure which application owns the file.
About WP-CLI and other shortcuts
Some guides suggest the command wp rewrite flush --hard as a way to flush rewrite rules and write the Apache file. The command and its effects depend on the installed WP-CLI version, the execution user, and whether the site is actually using Apache. Treat it as an optional administrator tool, not a substitute for identifying the server. Verify the command against the documentation bundled with your WP-CLI installation or ask the host before running a “hard” flush on a production site. The dashboard procedure is the safer first step for most administrators.
Verify the repair without creating new problems
- Open the homepage in a private window.
- Open one ordinary post, one page, and—if used—one category or tag archive.
- Open a custom post-type URL if a plugin recently registered one.
- Check both the site navigation link and the directly typed URL so you do not mistake a broken menu link for a rewrite failure.
- Review the server response after the test. A WordPress 404, an Apache/Nginx 404, and a server 500 error indicate different layers of the stack.
- Clear page-cache or CDN entries only after the origin responds correctly, then repeat the tests from a second browser or network.
Once the URLs work, document what changed: the time you flushed permalinks, whether .htaccess was edited, its final permissions, and whether the host changed a server setting. That record makes the next plugin activation or server migration easier to diagnose.
Preventing future permalink outages
- After activating a plugin that adds custom post types or rewrite endpoints, visit Settings > Permalinks and save once.
- Keep a dated backup of
.htaccessbefore manual edits. - Use the permalink structure field for a path pattern, not the full site URL. WordPress’s permalink guidance also recommends ending a custom structure with
%postname%or%post_id%so the final segment identifies the content. - Do not place unrelated directives inside the generated
# BEGIN WordPressand# END WordPressblock. - Record whether the site runs Apache or Nginx; the correct fix is different, and an Apache file cannot repair an Nginx server block.
When to contact your host
Escalate when you cannot access the server configuration, when mod_rewrite status is unknown, when permissions and ownership conflict, or when Nginx is serving the site. Include the exact failing URL, a working homepage URL, the result of the Permalinks save, the text of any error message, and whether the failure affects all content or one item. Ask the host to check the active virtual host/server block and its rewrite handling rather than merely reinstalling WordPress.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
