WordPress Permalink Settings: Structure, SEO and Safe Changes

Why I treat WordPress permalinks as a production setting

A WordPress site can look perfectly healthy until someone follows an old post link and gets a 404. The homepage loads. The dashboard works. Then one URL exposes the part nobody tested.

I think of a permalink as more than a pretty address. It is part of your content’s identity, your redirect plan, your cache behaviour, and the rewrite rules on the server. A bad choice made during installation can stay quiet for months before it becomes a migration problem.

When I investigate one of these tickets, I check the URL, the redirect response, the cache, and the web server configuration together. Looking at only the WordPress setting is rarely enough.

Changing the permalink structure in WordPress

Open Settings > Permalinks in the WordPress dashboard. You will see several predefined structures and a custom structure field.

• Plain: Uses URLs such as ?p=123.
• Day and name: Includes the full publication date, such as /2026/09/12/sample-post/.
• Month and name: Includes the year and month in the address.
• Numeric: Uses the post ID as the main part of the URL.
• Post name: Uses a short slug such as /sample-post/.
• Custom structure: Lets you build the address with structure tags.

For most new company sites, blogs, and WooCommerce projects, I start with Post name. Then I click Save Changes. That click matters even if you did not change the selected option, because WordPress rebuilds its rewrite rules.

Let me put it this way: choosing an option and leaving the page does not apply anything. On Apache, WordPress may also update the .htaccess file when you save.

Why Post name is usually my starting point

A URL such as /wordpress-permalink-settings/ is readable and does not become dated when the post is updated. That is useful, but it is not a reason to move every established site to a new structure.

A news site may have a real editorial reason to include the date. An older website may already have thousands of links using its current format. Changing those URLs just because shorter ones look nicer can create more work than value.

Keep working URLs stable. That is the quieter choice.

Choosing a structure without creating future redirects

The right permalink depends on how long your content stays useful, how often categories change, and whether you have a migration plan. SEO is only one part of the decision.

I think twice before using %category%. If an editor moves a post from one category to another, the URL may change. A post assigned to multiple categories can also make the chosen category less obvious, depending on the plugin and configuration.

For a new content site, I normally choose /%postname%/. For product catalogs, I avoid making product URLs depend on categories. A product moving from Accessories to Campaigns should not need a new address.

Posts, pages, categories, and custom post types

On the Permalinks screen, you can also change the category and tag bases. WordPress normally uses addresses such as /category/hosting/ and /tag/wordpress/.

You could change the category base to topic, producing /topic/hosting/. This affects existing category URLs, not just categories created later. Treat it as a URL migration.

WooCommerce adds another layer. Check the product, product category, and product tag settings separately. A page at /shop/ and a product category base of shop may conflict with the structure you intended. Slugs need room to breathe.

Custom post types follow the rules registered by their theme or plugin. A portfolio plugin may use /portfolio/; an events plugin may use /event/. After changing the general structure, I test one URL from every important content type.

Why saving permalinks can expose a 404

A post shown on the homepage does not prove that its individual URL works. WordPress usually does not serve that URL as a physical file. The web server must pass the request to WordPress through rewrite rules.

On Apache, those rules usually live in the .htaccess file in the WordPress directory. A typical root installation contains something similar to this:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
END WordPress

Existing files and directories are served directly. Other requests go to index.php. If WordPress is installed under a subdirectory, the paths must match that installation.

Back up .htaccess before editing it. I learned that on my first site, after placing a forum plugin’s rewrite rule in the wrong context and turning the whole site into a 500 error. The browser said only “Internal Server Error.” The Apache error log showed the actual mistake. Logs come first now.

OpenLiteSpeed and Nginx need different checks

OpenLiteSpeed can use Apache-compatible .htaccess rules in many WordPress setups. A cache can still make a fixed rule appear broken, so I clear the OpenLiteSpeed cache after testing the rewrite itself. If CyberPanel or another control panel manages the virtual host, I check its configuration before changing files manually.

Nginx does not read .htaccess. A common WordPress location block contains:

location / {
    try_files $uri $uri/ /index.php?$args;
}

try_files checks for a real file or directory, then sends the remaining request to WordPress. After changing Nginx configuration, test it before reloading:

nginx -t
systemctl reload nginx

The first command checks the configuration syntax. The second applies it without stopping the running service. On production servers, I prefer a reload when a restart is not needed.

Before changing URLs on a live site

Record the current setup first. I write down:

• The old and new permalink formats.
• Important URLs receiving traffic or external links.
• Post, page, category, and product URLs in the sitemap.
• Plugins and custom post types with their own rewrite rules.
• Redirect settings in the cache, CDN, security layer, and web server.

I also export the database before making the change:

wp db export /home/site/backups/before-permalinks-$(date +%F).sql

This writes an SQL export with the current date in its filename. The command must be run as the correct site user, and the backup directory must already exist and be writable. Check the file afterwards; a command that exits successfully is not the same thing as a tested restore.

On a busy site, I prefer to restore that export on a separate test machine or staging environment. A backup that has never been restored is still an assumption.

Redirects are part of the permalink change

Imagine the old structure is /%year%/%monthnum%/%postname%/ and the new one is /%postname%/. A broad redirect may handle simple cases, but edited slugs, unusual characters, and manually changed URLs still need individual checks.

If you use a redirect plugin, start with a few representative URLs. I check the old address first:

curl -I https://example.com/2025/08/sample-post/

The response should be a single 301 with the correct Location: header. Then I request the new URL and expect a successful response. If the old URL redirects to an intermediate URL before reaching the final page, I investigate the chain instead of accepting it.

Old URLs can also remain in menus, post content, image links, XML sitemaps, and structured data generated by plugins. As I explain in WordPress Site Health: How to Read and Fix the Report, a WordPress warning rarely tells you which layer is broken. The response headers and server logs usually narrow it down.

Checks I run after clicking Save Changes

The homepage is not a sufficient test. I check a few different paths:

1. Open a post, page, category, and tag in a private browser window.
2. Create a temporary draft and inspect its generated URL.
3. Confirm that an old URL returns the expected single 301.
4. Test menus, internal links, search results, categories, and tags.
5. On WooCommerce sites, test a product, cart, checkout, and account page.
6. Clear the cache and CDN, then repeat the test from another network.
7. Watch access and error logs for new 404 or 500 responses.
8. Check crawl and indexing reports in Google Search Console over the following days.

How to Read the Google Search Console Performance Report covers the traffic and query reports. After a URL change, I look at impressions and indexing as well as clicks.

Not every 404 is a failure. Typos and intentionally removed pages appear in logs too. Repeated requests for the same old URL usually mean an external link or internal reference still needs attention.

Symptoms that point to a permalink problem

Posts work, but pages return 404

Start by visiting the Permalinks screen and clicking Save Changes without changing the structure. If that does not help, inspect .htaccess, the Nginx try_files rule, permissions, and the server error log.

Do not jump straight to chmod 777. It changes the permission problem’s appearance without fixing its cause.

The same URL works with and without a trailing slash

WordPress, the web server, the CDN, and an SEO plugin may each be trying to control canonical redirects. Decide which layer owns that redirect and make the others agree. Three competing redirect rules are not redundancy; they are a future debugging session.

Turkish or other non-ASCII characters create an awkward slug

WordPress generally converts these characters into URL-safe slugs, but I still prefer to set short slugs manually. If a title changes, I usually keep the existing slug. If I change it, I add a 301 from the old address.

The dashboard works, but the frontend does not

This usually sends me toward the rewrite or cache layer. I test with a basic theme and temporarily disable relevant plugins on staging, then check the web server logs. Random file edits only make the trail harder to follow.

Using WP-CLI to inspect rewrite settings

With SSH access, WP-CLI gives me a direct view of the stored setting:

wp option get permalink_structure

Output such as /%postname%/ means the site uses the Post name structure. Empty output means the Plain structure is active.

To refresh the rewrite rules stored by WordPress, run:

wp rewrite flush

This cannot create a missing Nginx rule or repair a damaged Apache configuration. On Apache or OpenLiteSpeed, --hard can also write the WordPress rules to .htaccess:

wp rewrite flush --hard

I use that option only after backing up the existing file and confirming that WordPress owns the expected document root. A successful WP-CLI command does not prove that the request will pass through the correct virtual host.

If a migration also changes the domain, back up before using wp search-replace. Run it on staging first with --dry-run; an incorrect scope can damage serialized data or update values that should have stayed untouched.

My defaults for a new WordPress installation

After setting the domain, SSL, and homepage, I normally choose /%postname%/. I set category and tag bases according to the project, then test a page, category, tag, and any custom post type from outside the dashboard.

For WooCommerce, product URLs do not depend on category paths unless the project has a strong reason for that hierarchy. For content sites, I use short, stable slugs. If the date has no editorial purpose, I leave it out.

One support ticket still influences how I work. A misplaced rule in .htaccess left the homepage working while posts returned 500 errors. The permalink selection looked suspicious, but the Apache error log showed that the rule was being used in the wrong context. Restoring the backup and rebuilding the rules fixed it.

My order is simple: backup first, logs second, manual editing last.

Frequently asked questions

Which permalink option is best for WordPress?

For most blogs and company websites, Post name provides a short, maintainable structure. News sites may have a genuine editorial reason to include the date.

Will changing permalinks delete old posts?

No. The posts remain in the database, but their URLs change. Without 301 redirects, visitors and search engines may receive 404 responses at the old addresses.

Why do pages return 404 after saving the permalink settings?

The server is probably not applying the rewrite rules correctly. Check .htaccess on Apache or OpenLiteSpeed, the try_files rule on Nginx, and the relevant error logs.

Can changing permalinks harm SEO?

It can create traffic and indexing problems if old URLs do not redirect. Reduce the risk with a tested 301 map, an updated sitemap, corrected internal links, and a staging test before changing the live site.