WordPress permalinks: how to configure them for SEO

Short answer: go to Settings > Permalinks and choose Post name ( /sample-post/ ). That is the SEO-friendly structure for almost every WordPress site. Keep dates out of URLs unless you publish news where freshness matters. If you are changing structure on an established site, set up 301 redirects from the old URLs before you save.

The rest of this guide covers what a permalink actually is, why Post name is the right default, what happens when URLs stop working (the Save trick that fixes it), how to change structure without losing rankings, custom post type permalinks, and how to remove /category/ from category URLs.

What is a permalink?#

A permalink is the permanent URL for a post, page, category, tag, or archive in WordPress. Permanent is the key word – the URL should not change once content is published, because every link pointing to your content (inbound links, social shares, bookmarks, search engine indexes) uses that exact URL to find it.

Change a permalink after publication and every one of those references breaks unless you set up a redirect. That is why the permalink structure is one of the first things to configure when you set up a WordPress site, not something you change later.

Permalinks are generated from a template you pick in Settings > Permalinks. WordPress then builds every URL on your site from that template plus the individual post’s slug, date, category, or post ID – whichever your template uses.

The structure options and which to pick#

WordPress ships with six built-in structure options. The only one that matters for most sites is Post name.

Post name: /sample-post/

This is the right default for almost every site. Short URLs, keyword-rich, no date, no ID. Google’s own guidance prefers “simple, descriptive URLs” and this is exactly that. Every major WordPress SEO plugin recommends it. Every managed WordPress host defaults to it on new installs.

Pick this unless you have a specific reason not to.

Day and name: /2026/04/20/sample-post/

Useful only if you publish news, and even then it is a mixed bag. Pros: the date in the URL signals freshness and helps with archive browsing. Cons: URLs get long, and when an article gets traction two years later, the URL still says 2024 which looks dated.

If you want date information visible to readers, put it in the page content or meta, not the URL.

Month and name: /2026/04/sample-post/

Same tradeoffs as Day and name, slightly shorter. Same recommendation: only pick this for news sites where dated content is the point.

Numeric: /archives/123/

Never use this for public sites. There is no keyword in the URL, no context, no readable hint at what the post is about. Search engines, social shares, and human readers all benefit from descriptive URLs. The only use case is if you are running a site where URL obscurity is actually a feature, which is rare.

Plain: /?p=123

This is the WordPress default before you touch permalinks, and it is the worst option for SEO. Query-string URLs are harder for search engines to parse, nearly impossible for humans to read, and they break deep-linking conventions that the rest of the web relies on. Change it to Post name immediately after installing WordPress.

Custom structure

You can build your own template using structure tags like %postname% , %category% , %year% , %post_id% . This is useful for specific cases (news sites with a category prefix, multi-author blogs with an author slug) but for most sites, Post name alone is enough. The more tags you stack, the longer your URLs get, and long URLs hurt both readability and click-through rate in search results.

One common custom structure is /%category%/%postname%/ , which puts the category in every post URL. This looks organized but creates problems: posts in multiple categories get ambiguous URLs, and moving a post to a new category breaks its URL. Unless you have a clear editorial reason, skip it.

The Settings > Permalinks Save trick#

This is the single most useful piece of WordPress troubleshooting knowledge, and it applies far beyond permalinks themselves.

If posts and pages suddenly return 404 errors – the homepage works, the dashboard works, but every individual post URL is broken – go to Settings > Permalinks and click Save Changes without changing anything. Then test the posts again.

What this does: WordPress regenerates its rewrite rules. On Apache that means updating .htaccess . On Nginx there is no .htaccess , but WordPress still flushes its internal rewrite cache, which fixes a surprising number of permalink-related 404s.

When this fix works:

• After installing a new plugin that adds custom post types or custom rewrite rules
• After switching themes
• After restoring a backup
• After a migration where the rewrite rules did not come across cleanly
• After any plugin update that changes URL handling (WooCommerce, membership plugins, redirect plugins)

When this fix does not work, the issue is in the web server configuration, not WordPress. For Nginx, check the try_files directive – it needs to fall back to /index.php?$args for WordPress permalinks to resolve. For Apache, check that mod_rewrite is enabled and .htaccess is readable and has an AllowOverride All directive on the site’s directory.

On Hostney the Nginx configuration ships with the correct WordPress rewrite rules by default, so the Save trick is usually all you need.

Changing permalink structure on an established site#

This is where permalinks get dangerous. Changing the structure on a site that has traffic will break every existing link unless you set up redirects.

Imagine your site has used /2023/05/sample-post/ (Day and name) for three years. Every post has inbound links from other sites, social shares, email newsletters, search engine indexes. You decide to switch to Post name ( /sample-post/ ) for cleaner URLs going forward.

The moment you save the new structure:

• Every old URL returns 404
• Every backlink from other sites now points to a broken page
• Google sees a sudden wave of 404s and deindexes the affected URLs
• Social shares, bookmarks, and emails linking to the old URLs all break
• Rankings drop, sometimes permanently

The fix is 301 redirects from every old URL to the new URL. A 301 is a permanent redirect that tells search engines “this content has moved here, transfer the ranking signals to the new URL.” With 301s in place, you keep your rankings, inbound links continue to work, and users do not see broken pages.

The redirect approach

For structural changes (dated URLs to Post name, or removing a category prefix), the redirect pattern is usually a single rewrite rule because the slug at the end stays the same.

On Nginx, add a rule that captures the old structure and rewrites it to the new one:

# Old: /2023/05/sample-post/  New: /sample-post/
rewrite ^/\d{4}/\d{2}/(.+)$ /$1 permanent;

On Apache, do the same in .htaccess :

RewriteRule ^\d{4}/\d{2}/(.+)$ /$1 [R=301,L]

Test with a handful of old URLs before relying on the rule in production. Do not forget to check trailing slashes – WordPress typically enforces them, and redirects that drop the trailing slash can create redirect loops.

When a plugin is the better answer

If individual posts have had their slugs edited over the years, a single rewrite rule will not cover all cases. A redirection plugin (Redirection, Rank Math’s redirect module, Yoast Premium’s redirect manager) lets you set per-URL 301s through the WordPress admin. These plugins also track 404s that happen on your site, which is useful for catching old URLs you forgot to redirect.

The downside is that plugin-based redirects run in PHP, which is slower than web server rewrite rules. For a site with thousands of redirects, the plugin approach adds latency to every request. For a site with a handful of legacy URLs, it is fine.

Custom post type permalinks#

WordPress core handles permalinks for posts and pages automatically, but custom post types registered by plugins or custom code need their own rewrite rules.

A custom post type registered with 'rewrite' => array('slug' => 'product') will have URLs like /product/sample-product/ . If you want different URL handling – say, /shop/sample-product/ or no prefix at all – you set that in the register_post_type() call:

register_post_type('product', array(
    'public' => true,
    'rewrite' => array(
        'slug' => 'shop',
        'with_front' => false,  // ignore the permalink base
    ),
));

After changing any custom post type’s rewrite slug, go to Settings > Permalinks and click Save to flush the rewrite rules. The new URLs will not work until you do this – that is the same Save trick described above.

Plugins that register custom post types (WooCommerce, Easy Digital Downloads, The Events Calendar) often have their own settings pages for customizing URL slugs. WooCommerce, for example, has permalink settings under Settings > Permalinks > Product permalinks for the /shop/ base and product category URLs. Check the plugin’s documentation before writing custom code.

Removing /category/ from category URLs#

By default, WordPress category URLs look like /category/news/ . The /category/ prefix is hardcoded as “category base” and shows up in every category archive URL. Some sites want cleaner URLs – /news/ instead of /category/news/ .

The built-in option

Settings > Permalinks > Category base lets you change the prefix from category to something else: topics , section , or leave it as category . You cannot leave it blank through the admin UI – WordPress requires a non-empty value here.

The empty-base approach

To remove the prefix entirely, you need a plugin or custom code. Yoast SEO had a “remove category base” option for years, though recent versions moved it to Yoast Premium. Rank Math has the same feature in its free version under Rank Math > General Settings > Links.

The tradeoff is that removing the category base creates URL collisions. If you have a category slug news and also a page called news , WordPress has to decide which one to serve at /news/ . WordPress resolves pages first, so the page wins and the category becomes inaccessible at that URL. Check your category slugs against your page slugs before flipping this on.

Why the category base exists

The prefix exists because WordPress needs a way to tell categories apart from pages and custom post types when resolving a URL. /news/ could be a page, a post, a category, or a custom post type. With /category/news/ , there is no ambiguity. That is why removing it requires extra logic – the plugin or custom code has to add rewrite rules and a 404 fallback that redirects to the category if no page matches.

Permalink changes and caching#

Changing permalinks invalidates any cached version of the old URLs. Full-page caches (WP Rocket, W3 Total Cache, Nginx FastCGI cache, Redis object cache) all need to be purged after a permalink change or they will serve the old URLs from cache even after the rewrite rules are updated.

On Hostney, WordPress cache purging happens automatically when you change permalinks or save a post. On other hosts you may need to purge manually – check your hosting dashboard or caching plugin for a “purge all” or “clear cache” button.

CDN caches also need to be purged. Cloudflare, Fastly, and similar services cache responses based on the URL, so the old URLs will continue serving 404s from the CDN until you purge. Most CDN dashboards have a “purge everything” button for this.

Permalinks and SEO: what actually matters#

A lot of SEO advice fixates on permalinks as if the URL structure alone determines rankings. It does not. Here is what permalinks actually affect:

• Readability in search results. Google displays the URL (or a breadcrumb version of it) under the title. Clean, descriptive URLs get marginally higher click-through rates than query-string URLs.
• Keyword signal. Having the target keyword in the URL is a weak ranking signal. It helps, slightly, but it is not going to rescue a page with thin content or push past a better-optimized competitor.
• Stability. URLs that do not change are better for rankings than URLs that change. Inbound links keep working. Search engines do not have to re-crawl and re-index. This is the biggest SEO factor, and it is why the warning about changing structure on established sites matters more than the structure choice itself.
• Length. Shorter URLs are easier to share and slightly preferred by search engines. Stacking %category%/%year%/%postname% creates long URLs that add no SEO value.

What permalinks do not affect meaningfully:

• Core rankings on competitive queries (content, authority, and user signals dominate)
• Crawl budget on small sites (Google crawls everything regardless)
• Site speed (the structure does not add measurable load time)

So: pick Post name, leave it alone, and focus SEO effort elsewhere.

Common mistakes#

Changing structure on an established site without redirects. Covered above. This is the single biggest mistake. Always set up 301s first.

Using very long slugs. URL slugs should be short. Five or six words is plenty. /how-to-configure-wordpress-permalinks-for-better-seo-in-2026/ is a worse URL than /wordpress-permalinks/ .

Stuffing keywords into the slug. The title can be long and keyword-rich. The slug should be the short, memorable version of that. /cheap-best-wordpress-hosting-reviews-2026/ reads as spam. /wordpress-hosting/ reads as a page.

Using uppercase or special characters. URLs should be lowercase, alphanumeric, and hyphen-separated. WordPress handles this automatically when you generate slugs from titles, but if you are editing slugs manually, stick to [a-z0-9-] only.

Forgetting to flush rewrite rules after code changes. Any plugin or theme that registers custom post types, taxonomies, or rewrite rules needs the Save Permalinks trick to activate them. This catches developers who have just added a new post type and wonder why the URLs return 404.

Relying on the permalink for content organization. The URL is not the source of truth. WordPress resolves posts by ID internally and uses the slug only for the URL. Category changes, tag changes, parent page changes – none of these have to touch the URL as long as the slug stays stable.

How Hostney handles permalinks#

On Hostney, the Nginx configuration ships with the correct WordPress rewrite rules on every site – try_files falls back to /index.php?$args as WordPress needs. That means the Save Permalinks trick works out of the box, and you do not need to configure anything at the server level to get clean URLs.

When you change permalink structure on a site hosted with us, the automatic cache purging picks up the change and invalidates the affected URLs across our FastCGI and object caches. If you are using a CDN in front, you still need to purge that separately.

For sites migrating to Hostney from another host where permalinks were working, the structure transfers with the database. You may need to click Save on Settings > Permalinks once after the migration to ensure the rewrite rules are synced, but no server-level configuration is needed.

Summary#

Pick Post name ( /sample-post/ ) in Settings > Permalinks unless you have a specific reason to use dates. If URLs stop working after a plugin update, theme change, or migration, go to Settings > Permalinks and click Save – that fixes the majority of permalink-related 404s.

Never change structure on an established site without setting up 301 redirects from the old URLs to the new ones first. Redirects preserve rankings, inbound links, and user experience. Skipping them is the single most common way WordPress sites tank their own traffic.

For custom post types, the rewrite slug is set in register_post_type() and needs a Save Permalinks flush to activate. For cleaner category URLs, change the category base in the admin or use Rank Math to remove it entirely – but watch for slug collisions with pages.

And once it is set up: leave it alone. Stable URLs are worth more than the marginal keyword benefit of a restructure.