Subtle diagonal pinstripe pattern in light grey and cream, giving an impression of printed editorial paper

Fixing 404 Errors After Changing WordPress Permalinks

Many site owners in Australia who switch from the default ?p=123 structure to a prettier day-and-name or post-name format hit a wall when every page starts returning a 404. The homepage still loads, the dashboard works, but the moment someone clicks a post or a product page, the server replies with "Not Found". The frustration is real, especially for small businesses in Melbourne or Brisbane that have just relaunched their blog and were expecting a quiet Monday morning.

Permalinks live at the boundary between WordPress and the web server. When the URLs your database stores no longer match what Apache, Nginx, or IIS is willing to serve, the routing engine cannot find the content, and the request collapses into a 404. The good news is that the cause is almost always one of three things: a missing rewrite rules block, an out-of-date .htaccess file, or a server configuration that does not load mod_rewrite. Each one has a known fix, and none of them require rebuilding the site from scratch.

Before you reach for a backup or panic-roll, work through the diagnosis in order. The fix is usually a one-click save of the permalinks screen, a copy of the standard WordPress rewrite block, or a small tweak in your host's control panel. The walkthrough below covers the common paths, the platform-specific gotchas, and the safety nets you can put in place so the next URL change does not tank your search traffic during a busy AEST weekday.

Why Permalinks Break and Cause 404s

WordPress generates the URLs for your posts from a combination of the chosen structure, the post slug, and the rewrite rules that the CMS writes to .htaccess or passes to the server. When you click "Save Changes" on Settings → Permalinks, WordPress rebuilds its internal rewrite rules array and, on Apache, writes a new .htaccess file. If the write fails, the file is left in a state that no longer matches the database slugs, and the server responds with 404 for everything except the home page. The 404 itself is not always a true "file not found"; it is WordPress telling the server that no rewrite rule matched the incoming request, and the server then falling back to its default 404 handler.

Common triggers on Australian hosting stacks

That is why simply re-saving the permalinks can often restore access within a second, and why the Save Changes button is such a powerful troubleshooting step in this context. The trick is knowing which save, on which screen, will actually regenerate the right file for your server.

Quick Diagnostic Steps to Identify the Root Cause

Start by visiting a single post URL directly. If the homepage loads but a post URL returns 404, the permalinks are the prime suspect. If everything, including the dashboard, returns 404, the database connection is the more likely culprit and you should check wp-config.php before touching rewrite rules. If only a handful of old URLs 404, you are looking at a redirect problem rather than a permalink problem, and a 301 map is the cure.

Next, open Settings → Permalinks and look at the structure radio buttons. Switch to the Plain option, click Save, then switch back to your preferred structure and Save again. This two-step process forces WordPress to regenerate the rewrite rules and, on Apache, to rewrite the .htaccess file from scratch. Many site owners in Adelaide and Perth who manage their own hosting find that this single action resolves the issue without any further intervention. It also clears out any cached rules held inside WordPress's transients, which is sometimes enough on its own.

If the 404s persist, check whether your .htaccess file actually contains the WordPress block. Connect over SFTP or use the File Manager in cPanel, Plesk, or whatever panel your host provides, and look for a file at the document root. The file should include a block beginning with # BEGIN WordPress and ending with # END WordPress. If it is missing, the simplest fix is to copy the standard block from the WordPress documentation and paste it into a new .htaccess file, then re-save the permalinks to confirm WordPress can take ownership of the file.

For sites running on Nginx, IIS, or managed WordPress hosts such as WP Engine, Kinsta, or Pressable, the .htaccess file is not the answer. Instead, the rewrite rules need to live in the Nginx server block, the IIS web.config file, or the host's own permalinks interface. Each of these platforms has a different way of receiving the rules, and skipping this step is the single most common reason a permalink change works on a staging URL but breaks the moment a site is pushed to a managed production environment behind a content delivery network.

Restoring .htaccess and Flushing Rewrite Rules

The standard WordPress .htaccess block is short and worth memorising. For a site at the web root, it starts with a RewriteEngine On directive, includes a RewriteBase / line, has a rule that sends any non-existing file or directory to index.php, and finishes with a closing RewriteRule that stops the loop. If you are running WordPress in a subdirectory, the RewriteBase line should point to that directory instead. Copying this block verbatim will restore routing on most Apache and LiteSpeed servers without any further changes, and the same block is what WordPress would have written itself if the file were writable.

Sometimes the file is present but the permissions are wrong. WordPress needs to be able to write to .htaccess, which on most Australian shared hosts means ownership by the account user and permissions around 644. If the file is set to 444 or owned by root after a server migration, the Save Changes button will appear to work but the new rules will not actually be written. Fix the ownership through SSH with chown, or ask your host's support team to correct it, then re-save the permalinks and confirm the file's modification timestamp updates.

For developers who prefer a programmatic approach, the flush_rewrite_rules() function does the same job as the manual save. Calling it once after a permalink change, after registering a custom post type, or after adding new query variables clears the cached rules and forces WordPress to regenerate them. A small mu-plugin that hooks into admin_init and runs the flush only when a flag is set is a clean way to automate the process on a multisite network. The same idea, applied to a custom WooCommerce product type, is covered in a detailed walkthrough that shows how new product types affect the rewrite registry and why their absence is a frequent source of post-save 404s.

When all of the above fails, the last thing to try before contacting your host is to delete the .htaccess file entirely and re-save the permalinks. WordPress will recreate it from scratch. If the recreation succeeds, the 404s disappear; if not, the problem is almost certainly the server configuration rather than WordPress itself, and a support ticket with your local provider is the fastest path forward.

Handling Nginx, IIS, and Managed WordPress Hosts

On Nginx, .htaccess is ignored, so the rewrite rules need to be expressed as try_files directives inside the server block. A typical configuration tries the request as a file, then as a directory, then falls back to /index.php?$args. If your Nginx config is missing that last line, every pretty permalink will 404. Australian studios running sites on DigitalOcean, Vultr, or UpCloud droplets handle this through a custom server block, while those on cloud platforms such as AWS Sydney or Google Cloud's Melbourne edge rely on the platform's WordPress image to ship a working config out of the box. Either way, a config change requires a reload, not just a file save, and forgetting the reload is a common reason the fix appears not to take effect.

IIS, used by some corporate and government sites including a few local councils, stores its rewrite rules in web.config. The URL Rewrite Module must be installed, and the rules use a different syntax that maps directly to the WordPress equivalent. If you are migrating a site from Apache to IIS, the Microsoft-provided import tool will translate the .htaccess block for you, but it is worth checking the result because path separators and case sensitivity often need a manual pass on Windows-based servers.

Managed WordPress hosts take a different approach. They often hide the .htaccess or web.config file behind their own caching layer, and any direct edit is overwritten on the next deploy. The right place to make changes is the host's permalink tool, which is usually a one-click "clear cache and flush rules" button. If that button is not available, opening a support ticket is faster than fighting the platform. For studios that run sites across multiple hosts, a deploy script that calls the host's API to clear caches and flush rules after a permalink change saves a lot of late-night Sydney-time troubleshooting.

A practical tip for site owners down under: when you change permalinks on a live site, the .au search engines and any local SEO tools you use will pick up the new URLs almost immediately, but the old URLs still receive traffic from bookmarks, old email campaigns, and links from local directories such as TrueLocal and Yellow Pages. Pair the permalink change with a redirect plan rather than treating it as a settings tweak in isolation.

Preventing Future 404 Breakage with Redirects and Monitoring

The cleanest way to avoid 404s after a permalink change is to never break the old URLs in the first place. Keep the previous structure live until you have written and tested a full set of 301 redirects, then switch the new structure on. The Redirection plugin handles this elegantly by tracking 404s and turning the most common ones into permanent redirects over time. For larger sites, a server-level redirect map is faster and reduces load on WordPress during a traffic spike, which matters when a national campaign or a Product Hunt launch sends a wave of visitors your way.

A second layer of safety comes from monitoring. Set up a weekly crawl with a tool such as Screaming Frog, Sitebulb, or the free version of Ahrefs, and alert on any spike in 4xx responses. A small Sydney-based agency I worked with uses a Uptime Robot heartbeat on a key landing page that returns 200 only when the rewrite rules are healthy; the moment the heart skips, an SMS wakes the on-call developer. The same idea, scaled up, becomes a health check for an entire multisite network where one broken pattern can take down a hundred micro-sites at once.

Document every permalink change in a changelog that includes the date, the structure before and after, and the redirect map that was applied. When the next site owner asks why a particular URL from 2019 still works, the answer is in the changelog rather than buried in an old Slack thread. Combined with a tested backup routine and a staging environment that mirrors production, the documentation turns a fragile URL change into a routine maintenance task. Finally, treat the .htaccess file as part of your deployable code. Keep it in version control, lint it before each release, and include its expected hash in your post-deploy smoke tests. A one-line change in .htaccess is enough to take down every pretty permalink on a site, and the difference between a five-minute fix and a five-hour outage is whether the regression is caught by an automated test or by a frustrated visitor in Brisbane.

Server or platform Where the rules live How to flush them Common pitfall
Apache with .htaccess .htaccess in the document root Settings → Permalinks → Save File not writable after a migration
LiteSpeed .htaccess in the document root Save permalinks or LSWS cache flush Cached old rules after a quick edit
Nginx server block, try_files directive nginx -s reload after editing the config Missing fallback to index.php
IIS web.config under the site root Restart app pool or run iisreset URL Rewrite module not installed
Managed WordPress Host's permalink and cache tool One-click flush in the host panel Direct .htaccess edits get overwritten

Quick symptom reference