WordPress Permalink Structure for SEO

WordPress's permalink setting is a thirty-second choice with a forever consequence: it stamps the URL pattern on every post the site will ever publish, and changing it later converts every published URL into a migration. The correct choice is boringly settled — Post name — and the interesting content of this guide is everything around it: the wrong options' actual costs, the slug craft within the right structure, and the change-safely procedure for sites that chose badly years ago.

The options, judged

Post name (/%postname%/) — the answer for almost everyone: short, readable, keyword-natural, dateless — every property the URL rules want, with the evergreen-friendly absence of timestamps that age content on sight. Day-and-name / month-and-name: the news-site pattern — legitimate for genuine news operations (date context aids readers and archives), a self-inflicted freshness tax for everyone else: /2017/03/guide/ announces staleness regardless of updates. Plain (?p=123): the unset default — opaque, keyword-free, and the tell of an unconfigured site. Custom structures with /category/: the tempting one — it mirrors site hierarchy in URLs at the cost every recategorisation becoming a redirect event; the flat-URLs-breadcrumbs-carry-hierarchy pattern (per the store structure logic) ages better for most sites.

Slug craft within the structure

The setting fixes the pattern; per-post slugs stay editorial, per the URL guide: trim WordPress's auto-slug of stopwords and title filler (the-complete-guide-to-choosing-... → choosing-x), keep the keyword identity, keep it stable — the slug is settled at publish and never touched after (title edits are free; slug edits are redirects). House rule worth enforcing: slugs reviewed in the pre-publish pass, because the auto-generated ones ship verbose by default.

Changing structure on a live site (the careful procedure)

When an inherited site runs dated or plain permalinks and the change is genuinely justified (it usually is, once): treat it as the migration it is — WordPress auto-redirects some changes and not others (canonical redirects catch simple cases unreliably; never rely on them), so: export the URL inventory, generate the old→new map (pattern-based — date-stripping is one regex), implement as explicit 301s in the redirect manager or server config, then flip the setting, then verify per the edge-hunting routine: sample old URLs one-hop to new, internal links updated (search-replace old patterns in content), Search Console watched through the settling weeks. Do it in a quiet season, never stacked with other changes, and expect the standard dip-and-recover shape.

Frequently asked questions

Is it worth changing from dated URLs on an old, established blog?

The trade: permanent freshness-optics and CTR gains versus weeks of settling risk on a working site. Worth it for sites whose content is genuinely evergreen and actively maintained (the dated URLs actively undercut the refresh programme's credibility); skippable for sites where rankings are fragile and the calendar never quiets. If yes: the full procedure, once, forever.

Do trailing slashes or .html suffixes matter?

Consistency matters; the variant doesn't — WordPress enforces its canonical form with redirects natively. The check worth running: that internal links use the canonical form directly (theme/builder-generated links occasionally ride the redirect, per the never-internally rule).

Should slugs contain the focus keyword?

Naturally, yes — the slug usually is the topic's name, per the URL guide's keyword-natural principle — and the effect is minor: a clean descriptive slug aids CTR display and relevance at the margin, while keyword-stuffed slugs read spammy in the one place users always see. Name the page what it is; spend the optimisation energy where the hierarchy pays — content and links (our end).