Permalinks look like a cosmetic setting buried in Settings > Permalinks, but they are actually a structural decision. Every internal link, every backlink pointing at your site, every cached page, and every search engine index entry depends on the URL pattern you choose. Get it right when the site is new and you never think about it again. Get it wrong and fix it later, and you are signing up for redirect maps, crawl budget waste, and weeks of watching rankings wobble.
Why permalinks matter more than they look
A permalink is not just a pretty URL. It is an identifier that search engines, caching layers, and other websites treat as the canonical address of a piece of content. Full-page caching systems like LiteSpeed Cache store a cached copy keyed to the exact URL. Cloudflare’s edge cache does the same at the network edge. Change the URL and you are not editing a setting, you are minting a new page in the eyes of every system that already knows the old one.
That is fine for a brand-new site with no backlinks and no indexed pages. It is a real cost for anything that has been live for months or years.
The structures WordPress offers
Under Settings > Permalinks, WordPress gives you a handful of built-in options plus a custom structure field. The ones worth knowing:
- Plain: query-string URLs like
?p=123. Ugly, hard to remember, gives search engines and readers no information about the page. Avoid it for anything public. - Day and name / Month and name: URLs that embed a publish date, such as
/2024/03/post-title/. This looks tidy for a news site but it locks the date into the URL forever. Update an evergreen guide two years later and the URL still says 2024, which undercuts the very freshness signal you are trying to send. - Post name:
/post-title/. Clean, readable, timeless. This is the structure most sites should use. - Custom structure: lets you build your own pattern, for example prefixing a category:
/%category%/%postname%/.
What to pick for a new site
For the vast majority of WordPress sites, plain Post name (/%postname%/) is the right default. It is short, readable, portable across content types, and it does not bake in a date or category that might change later. If you run a large site with genuinely distinct content silos (a blog next to a documentation section next to a shop, say) a category prefix can help humans and crawlers understand the site’s shape. But add that prefix only if the category itself is stable. Categories get renamed and reorganized far more often than people expect, and a category-based permalink structure means every reorg is also a URL migration.
A few practical habits pair well with post-name permalinks:
- Set the slug deliberately when you publish, rather than letting WordPress auto-generate it from a title you might edit later. The title can change; treat the slug as closer to permanent.
- Keep slugs short and keyword-relevant, but do not stuff them. A slug like
/permalinks-guide/reads better and ages better than a padded, over-optimized version. - Decide on trailing slash consistency once and let WordPress handle it. Mixing
/page/and/pageas separate URLs invites duplicate content confusion.
What changing permalinks later really costs
If you switch a live site’s permalink structure, several things happen at once:
- Every old URL 404s unless you build redirects. WordPress does not do this for you when you change the global setting.
- Backlinks stop being useful until the redirect is in place, and even then you are passing link equity through a redirect hop rather than directly.
- Search engines have to recrawl and reindex every affected URL. Rankings for those pages can dip during the transition, sometimes for weeks, before settling back.
- Caches go stale in a very literal sense. LiteSpeed Cache and Cloudflare’s edge cache are both keyed to URL, so a structure change invalidates your entire cached page set at once. Every visitor after the change hits an uncached, freshly rendered page until the cache rebuilds, which is a real load spike on a busy site.
- Internal links break: menus, widgets, hardcoded links inside old post content, anything that was not written using WordPress’s dynamic linking functions.
None of this means you can never change permalinks. It means you should treat it as a migration project with a checklist, not a settings tweak.
A safe migration recipe, if you have to change
Sometimes you inherit a site on plain permalinks, or you are consolidating two sites, or a rebrand genuinely requires new URLs. Here is a safe sequence.
- Map every existing URL before you touch anything. Crawl the live site with any standard crawler and export the full URL list, or pull it directly with wp-cli:
wp post list --post_type=post,page --field=url - Decide the new structure and generate the new URL for each old one. For a straightforward post-name migration this is usually a mechanical transform; for anything with a category or date change, do it by hand or with a script you have checked.
- Build a 301 redirect map before you flip the setting, not after. A dedicated redirection plugin or your own rewrite rules in the server config both work; the important part is that every old URL has a destination the moment it starts 404ing.
- Change the permalink structure in WordPress, then flush rewrite rules explicitly:
wp option update permalink_structure '/%postname%/' wp rewrite flush --hard - Purge caches everywhere, in order: object cache, LiteSpeed page cache, then Cloudflare’s edge cache last, so nothing gets re-cached from a stale source.
- Verify the redirect map with spot checks across post types, pagination, and any custom taxonomies, not just the homepage and a sample post.
- Resubmit your sitemap to search engines and watch crawl stats for a few weeks. A brief dip in indexed pages or impressions is normal; a prolonged one usually means a redirect gap somewhere.
- Grep old content for hardcoded internal links and fix the worst offenders rather than relying on redirects to catch everything indefinitely.
If your hosting stack already handles cache layer coordination for you, so much the better. A managed host like ServerBorn, for instance, can purge LiteSpeed and Redis caches in the right order as part of a deployment, which removes one variable from an already fiddly migration.
Takeaway
Permalinks are cheap to get right at the start and expensive to fix later. Pick /%postname%/ for a new site unless you have a specific, stable reason to do otherwise, set slugs deliberately, and treat any future change as a full migration with a redirect map, not a quick settings flip. The few minutes you spend choosing well on day one save the redirect spreadsheets and ranking dips that come with changing your mind two years in.