WordPress Posts Return 404: Fix Permalinks and .htaccess

If your WordPress home page loads but posts and pages return 404, the cause is more likely the rules that route addresses to WordPress than the content itself. Take a backup, save the Permalinks setting again without changing it, and then check that the WordPress rule block in .htaccess is intact. If you run a blog, a company site or a small shop, the diagnosis table walks you through the order of checks.

Keep a 404 apart from a soft 404 while you work; soft 404 errors explains the difference. The WordPress SEO settings checklist covers the permalink setup itself.

What this symptom tells you

Three quick tests

1. Open the home page. If it loads, WordPress itself is running.
2. Open the pretty address of one post. A 404 here confirms a routing problem.
3. Open the same post with ?p= and its ID. If it loads, the content is in place and only the pretty addresses fail.

The WordPress permalink documentation (Opens in a new tab) says the default Plain structure looks like ?p=N and works on all server environments, so the third test separates a routing fault from a content fault. Practical suggestion: you can read a post's ID from the address of its edit screen in the dashboard.

What the documentation says about the server

The same page says your hosting provider is expected to have configured the web server for pretty and almost pretty permalinks, and that you should contact the provider if it has not. The fault can therefore sit in the server configuration rather than in your files, and the fix then comes from the host.

Sorting the problem before touching files

A short decision rule

If the home page and the ?p= address work and pretty addresses fail, it is a rules problem: save the setting again, then look at the file. If everything fails, including the home page, it is not a pretty-permalink rule problem. If one post fails, leave the server rules alone and check the post.

Rewriting and the basic rule block

The block in the documentation

The WordPress Apache HTTPD and .htaccess documentation (Opens in a new tab) says WordPress modifies the file to handle pretty permalinks, and gives this basic block:

# BEGIN WordPress
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
# END WordPress

Reading the block

Reading the block line by line helps you locate the fault. The two RewriteCond lines select requests that match neither a real file nor a real directory, and the final RewriteRule sends those requests to index.php, where WordPress resolves the address. If one of these lines is missing, pretty addresses stop working. The documentation does not explain the individual lines. Practical suggestion: treat this reading as a working assumption drawn from how the rules are written.

What the documentation covers about mod_rewrite

The page mentions mod_rewrite only once, in the Options section, where it says that FollowSymLinks is necessary for mod_rewrite. It does not cover AllowOverride, file permissions or backups, and has no 404 troubleshooting steps. Those settings sit with your hosting provider, who should be asked if the block looks fine and the 404s remain.

Saving the permalinks again

The lowest-risk first step is to open the Permalinks screen under Settings and save without changing the selected structure. Whether saving rewrites the rule block is not stated in the documentation; the step is a practical suggestion that costs little, because it changes no structure and can be undone.

1. Take a backup. Copy the contents of .htaccess into a separate text file.
2. Open Settings, then Permalinks. If your dashboard is not in English, menu names can look different.
3. Press the save button without changing the structure.
4. Open the pretty address of a post in a new tab.
5. If it still returns 404, continue with the file.

Possible outcomes of saving

Do not switch structures to fix it

Changing the structure while hunting a fault creates a new problem, because every address changes and needs a redirect. Opening the ?p= address by hand runs the same test with no risk.

Repairing the file

Backup first

The file may hold rules besides WordPress's own: redirects, security rules, cache rules. Do not delete them during repair. Copy the whole file, then compare the WordPress section with the block in the documentation.

How the block gets damaged

The documentation's restore note

The page says it may be used to restore a corrupted .htaccess file, for example one damaged by a misbehaving plugin. File permissions and writability are not covered. If you cannot save the file, use the file manager in your hosting panel or ask support.

Editing by hand

• Open the file in a plain text editor, because word processors can add formatting characters.
• Keep the BEGIN WordPress and END WordPress lines as they are.
• Do not nest blocks inside each other.
• Check that line breaks survive when you paste from the documentation.
• Reopen the file after saving to confirm the change stuck.

Practical suggestion: change one thing at a time and open a post address after each change. After a large edit it is hard to tell which line caused a fault.

When a plugin damaged it

The documentation gives a misbehaving plugin as an example of what can corrupt the file. Security, cache, redirect and SEO plugins are kinds that can touch .htaccess, though what each one changes is described in its own documentation, not here.

Finding the plugin

1. List plugins installed or updated closest to the time the problem began.
2. After a backup, deactivate one of them.
3. Open a post's pretty address after each deactivation.
4. If the address works, the plugin you just turned off is the suspect; review its settings before reactivating it.
5. If the problem returns once it is active again, switch off its option to write to .htaccess or replace the plugin.

Before deleting the plugin

Look in its settings for options about writing to .htaccess, adding redirect rules or generating security rules. Switching one off may remove the problem while keeping the plugin's other functions. If you remove the plugin, lines it left in the file may remain; the documentation does not describe this, so reread .htaccess afterward and leave alone any line you cannot trace to the plugin.

Servers that are not Apache

.htaccess belongs to Apache. If your server runs Nginx or other software, the rules live in the server configuration, and the documentation says nothing about Nginx here. Find out which server you have from the hosting panel or the provider. Editing .htaccess on an Nginx server achieves nothing.

After a hosting move

If posts started returning 404 after you moved the site, rewriting may not be configured on the new server. The WordPress documentation assigns this to the host: configuring the server for pretty permalinks is the provider's job.

Questions for the provider

• Which web server software runs here, Apache or something else?
• Is .htaccess processed in the site's root directory?
• Is the rewrite module active?
• Does the server error log hold an entry for the time the problem began?

The documentation says nothing about AllowOverride or enabling modules, so these questions belong with the provider.

A support ticket that gets answered

1. The symptom: the home page loads, pretty addresses return 404, the ?p= address loads.
2. When it started and what changed just before: a plugin update, a move or a setting.
3. One sample post address for testing.
4. What you already did: saved permalinks again, repaired the block against the documentation, eliminated plugins.
5. What you need from the provider: the server type, confirmation that rewriting is set up and the relevant error log entries.

Leave administrator passwords, database details and other secrets out of the ticket.

When only some posts fail

The WordPress documentation says permalinks should not change. If a slug did change on a published post, send the old address to the new one with a permanent redirect, and point it straight at the final address so no chain forms.

When the fault seems to exist only on some devices

An administrator who is logged in may see a page that a visitor cannot. When the fault seems to exist only on some devices, repeat the test in a logged-out window before drawing a conclusion. The documentation has nothing further on this point.

Practical suggestion: also keep a printed or offline copy of the booking phone number for the day something like this happens. A page that is down should not leave a customer with no other route.

404 or a server error?

How Google treats these

The Google documentation on HTTP status codes (Opens in a new tab) says all 4xx errors except 429 are treated alike: the page is treated as nonexistent, a previously indexed URL is removed from the index, and newly encountered 404 pages are not processed. For 5xx and 429 errors, crawlers slow down for a while in proportion to the number of failing URLs; indexed URLs are kept at first but dropped if errors persist, and the crawl rate rises gradually once the server answers with 2xx again. The page gives no time frame. A 2xx status paired with error-like content can be flagged as a soft 404 in Search Console. The status meanings are laid out in the HTTP status codes guide.

Checking the crawl after the fix

• Open five address types: a post, a page, a category archive, a tag archive and an attachment page.
• Confirm each returns 200 with the right content.
• Invent an address that cannot exist and confirm a real 404 page appears.
• Sample several sitemap entries.
• Clear the cache plugin, the host cache and any CDN cache.
• Review the page indexing report in Search Console a few days later.

Cache layers

If a browser still shows a 404 after the fix, suspect caching. A cache plugin, the host cache or a CDN can hold the old error page. Clear every layer and retry in a private window or on another device. The documentation says nothing about caching, so treat this as a practical suggestion.

Watching Search Console

The Page indexing report in Search Console can list addresses seen as 404. If you use the interface in another language, the report name can look different. Read the list again a few days after the fix and separate addresses that should exist from content you removed on purpose. The documentation does not say how soon an address is processed again, so build waiting time into the plan.

Example scenario: a neighborhood bookbinding studio's website

Example scenario: A bookbinding studio updates a security plugin and finds that its technique posts return 404, while the home page loads.

1. The owner runs the three tests: the home page loads, the pretty address fails, the ?p= address loads. It is a rules problem.
2. She backs up the files and copies the .htaccess contents.
3. She saves the Permalinks setting unchanged; the problem stays.
4. She finds the WordPress block missing from .htaccess and writes back the documented block, leaving the other rules alone.
5. She opens the security plugin's settings and turns off its option to write to the file; the problem does not return.
6. She opens five address types, invents an address to confirm the 404 page, and clears the cache.

Prevention

An update-day routine

1. Back up files and database and keep a separate copy of .htaccess.
2. Apply updates one at a time, opening a post and a category archive after each.
3. If a fault appears, roll back the last update and note which one it was.
4. Test the five address types again at the end.
5. File the record with a date.

Avoid steps you cannot undo

While diagnosing, stay away from steps that delete data or change the structure: switching structures, deleting plugins, resetting the database, bulk-deleting files. Every diagnostic step should be reversible, such as saving the setting again, deactivating a plugin for a moment or rewriting the block with a backup in hand. Before trying anything irreversible, ask the host for a backup or a restore point.

The SEO side

A post that returns 404 shows an error to crawlers as well as readers. Per the Google documentation, a 404 address is removed from the index and newly encountered 404 pages are not processed, and no figure for the size of the loss is given. The sooner the fault is fixed, the fewer indexed addresses are affected. After the repair, confirm that the sitemap answers cleanly and that its addresses return 200.

Show readers something during repair

A visitor facing a 404 cannot tell whether a post exists. If the repair will take hours, ask your host about maintenance page options. Per the Google documentation, a server error status slows crawling for a while but does not drop indexed addresses at once.

Handling the first hour after the 404 reports

When readers report 404 pages, the first hour decides whether the site loses a morning or a week. A fixed order of moves keeps you from changing three things at once and not knowing which one worked.

Example scenario: a pottery studio's online shop pages

A pottery studio runs a blog and a few workshop pages. One morning the home page loads, but the workshop booking page returns 404. The owner is tempted to reinstall a theme, update every plugin and ask the host for help at the same time. Instead the studio follows a written order: confirm the content exists, save the permalink setting again, inspect the rule block, then leave the host for last. Changing one thing at a time makes the cause visible.

Response order table

Closing checks

• Home page, one post, one page and one category address all open.
• The same result appears on a phone and in a private window.
• Any caching plugin was cleared.
• A copy of the changed file sits in a separate place.
• A short note records which step solved it.

When to stop editing and call the host

Practical suggestion: if steps two and three do not fix the addresses within a reasonable working session, stop editing and contact the provider with the list of what you already tried. A clear list shortens their diagnosis.

Frequently Asked Questions

The home page loads but posts return 404. What should I do first?

Take a backup, then save the Permalinks setting under Settings without changing the structure. If that does not help, compare the WordPress rule block in .htaccess with the block in the documentation.

What is the basic rule block in .htaccess?

The WordPress documentation gives it between the BEGIN WordPress and END WordPress lines: RewriteEngine On, RewriteBase /, an index.php rule, two RewriteCond lines and RewriteRule . /index.php [L].

Can a plugin corrupt .htaccess?

Yes. The documentation says its rule block can restore a file damaged, for example, by a misbehaving plugin. Deactivate plugins one at a time to find the suspect.

What if my server runs Nginx?

The documentation says nothing about Nginx here. .htaccess is for Apache, and Nginx rules live in the server configuration, so contact your hosting provider.

Will Google drop posts that return 404?

Per the Google documentation, 4xx errors other than 429 are treated alike and a previously indexed URL is removed from the index. The documentation gives no time frame.

Who fixes it if the server is not configured?

The WordPress documentation says your hosting provider is expected to configure the web server for pretty permalinks and that you should contact the provider if it has not.

Conclusion

When posts return 404, work through the cause in order. Back up, confirm with the ?p= address that the content is in place, save the Permalinks setting unchanged, repair the WordPress block in .htaccess against the documented block, and eliminate plugins one by one if the fault persists. If the server is not Apache or the configuration sits with the host, ask the provider for help.

Once the site is healthy again, if you want to add content that serves readers, take a look at our content writing service.