WordPress Permalinks and URL Structure

Choose your permalink structure once, at launch, and use the post name. /blog/your-post-title — short, readable, and it does not date your content.

The reason to be deliberate is not that one structure ranks better. It is that changing it later breaks every URL you have published, and fixing that means redirecting all of them.

And on what Google actually says about URLs: its guidance is about readability, not keywords. "use readable words rather than long ID numbers in your URLs", and "we recommend using hyphens (-) instead of underscores (_) to separate words in your URLs, as it helps users and search engines better identify concepts in the URL."

Google's URL structure documentation gives no guidance on URL length and none on keyword usage. The advice to pack keywords into slugs does not come from Google.

---

The options, and what each costs

Settings → Permalinks.

Structure	Example	The catch
Plain	/?p=123	Not readable, and it disables WordPress's core sitemaps
Day and name	/2026/09/03/post-title/	Dates your content visibly, and lengthens every URL
Month and name	/2026/09/post-title/	Same problem, slightly shorter
Numeric	/archives/123	The ID-number pattern Google explicitly advises against
Post name	/post-title/	The default recommendation
Custom	Whatever you define	Useful for a prefix like /blog/; risky beyond that

Why post name wins for a blog: it is readable, it is short, and it does not tell every visitor how old the article is before they open it.

That last point is practical rather than theoretical. An evergreen guide published three years ago with /2023/ in its URL is judged as stale by readers who never open it — and by writers deciding whether to cite it.

The one custom structure worth considering is a section prefix, such as /blog/%postname%/, which keeps posts visibly separate from pages. Decide it at launch, since adding or removing a prefix later is the same expensive change as any other.

---

Writing the slug itself

WordPress generates a slug from your title, and it is usually worth editing.

• Shorten it. A title of twelve words does not need a twelve-word URL — trim to the identifying phrase
• Remove filler. "a", "the", "and", "how to" can usually go without losing meaning
• Keep it readable. The test is whether someone could guess what the page is from the URL alone
• Hyphens, not underscores, per Google's explicit recommendation
• Lower case, always. Mixed case creates two URLs that may both resolve
• No dates, no version numbers, unless the content genuinely is versioned
• Use your audience's language. Google's guidance: "Use words in your audience's language in the URL (and, if applicable, transliterated words)"

What not to do is stuff it. A slug repeating the same term three times is the URL-shaped version of a pattern Google defines as keyword stuffing — "filling a web page with keywords or numbers in an attempt to manipulate rankings".

And once published, leave it alone. Editing a slug after publication breaks the URL exactly as a structure change does, on a smaller scale. If a slug must change, redirect it.

---

Changing permalinks on a live site

Sometimes it is necessary — inheriting a site on the date-based structure, or removing a prefix that no longer makes sense. It is doable and it is not casual.

Seven steps.

Step 1 — Establish whether it is worth it

Be honest. A site with 30 posts and little traffic can absorb this easily. A site with 500 indexed URLs and steady traffic is taking real risk for a readability gain.

"The URLs are ugly" is a weak reason on an established site. "Every URL contains a date and our content is evergreen" is a reasonable one.

Step 2 — Export every current URL

Before changing anything. From your sitemap, from Search Console's Pages report, and from a crawl if you have one.

This list is the thing that makes the redirect map possible, and it cannot be reconstructed after the change.

Step 3 — Back up the database

Files and database. The permalink change itself is a settings change, but the redirect work that follows touches a great deal.

Step 4 — Change the setting, then verify rewrite rules

Settings → Permalinks, select, save. Saving that screen regenerates the rewrite rules, which is also the standard fix for a site where every URL suddenly returns 404.

Step 5 — Build the redirect map and implement 301s

Old URL to new URL, one to one. Not everything to the homepage — that loses the mapping and is treated as a soft error rather than a redirect.

Where the change is a consistent pattern — removing a date prefix, adding a section prefix — a rule handles it in one line rather than hundreds of individual entries. Test the rule against a sample before trusting it across the site.

Step 6 — Update internal links

Every internal link pointing at an old URL now goes through a redirect. It works, and it is slower and messier than pointing at the destination.

Update them in the content, not just at the redirect layer. This is the step people skip and the one that leaves a site slow and tangled for years.

Step 7 — Resubmit the sitemap and watch for a month

Submit the sitemap, then watch Search Console's Pages report for crawl errors and for the old URLs moving to a redirect status.

Expect a temporary dip. Recrawling takes time, and rankings usually settle back. Do not make a second change while the first is settling, or you will not know which caused what.

Keep the redirects permanently. External links to the old URLs will keep arriving for years.

---

The problems people actually hit

Every URL 404s after the change. Rewrite rules did not regenerate. Re-save Settings → Permalinks — that alone fixes it in most cases, and it is also the standard fix after a migration.

Redirect chains. Old URL redirects to a second old URL which redirects to the current one. Update the first redirect to point at the final destination, and check the chain whenever you change a URL twice.

Mixed-case URLs. Both cases resolving means duplicate URLs for one page. Force lower case, and redirect.

Trailing slash inconsistency. Pick one, apply it consistently, and let WordPress redirect the other form.

Pagination breaking. Custom structures can conflict with /page/2/. Check pagination immediately after any structure change, because it is the first thing to break and the last thing anyone tests.

A prefix colliding with a page. A /blog/ prefix and a page also at /blog/ will fight. Decide which one owns the path.

---

What does not matter as much as you think

Keywords in the URL. Google's URL documentation does not mention them. Readability is what the guidance is about.

URL length. No guidance from Google on this either, though a short URL is easier to read, share and cite.

Stop words. Removing "the" and "a" makes a slug tidier. It does not do anything else.

Categories in the URL. A structure including the category dates badly if you ever reorganise categories — and reorganising is common, as covered in WordPress categories and tags for SEO.

Trailing slashes. Consistency matters. Which one you pick does not.

---

Frequently asked questions

What is the best permalink structure for WordPress?
Post name, giving a short readable URL. Google recommends readable words rather than ID numbers and hyphens rather than underscores, and gives no guidance on URL length or keyword usage. A section prefix such as /blog/ is a reasonable variation if decided at launch.

Should I include the date in WordPress URLs?
Generally not for evergreen content. A visible year makes an article look stale to readers and to writers deciding whether to cite it, and it lengthens every URL. Date structures suit news sites where the date is genuinely part of the identity.

Does changing permalinks hurt SEO?
It can, if every old URL is not redirected. The change breaks every published URL, so it needs a complete one-to-one redirect map, updated internal links, and a resubmitted sitemap. Expect a temporary dip while pages are recrawled.

How do I change permalinks without losing traffic?
Export every current URL first, back up, change the setting, implement one-to-one 301 redirects, update internal links in the content rather than relying on the redirects, resubmit the sitemap, and watch Search Console for a month.

Why does my WordPress site show 404 on every page?
Rewrite rules did not regenerate. Go to Settings → Permalinks and save without changing anything, which regenerates them. It is also the standard fix after a site migration.

Do keywords in the URL help rankings?
Google's URL structure documentation gives no guidance on keyword usage, and its recommendations concern readability. Repeating a term in a slug approaches what Google defines as keyword stuffing.

Should I edit the slug after publishing?
Only if necessary, and with a redirect. Editing a published slug breaks that URL exactly as a structure change does, on a smaller scale.

Should the URL include the category?
Usually not. A category in the URL dates badly if you ever reorganise your categories, which is common, and every reorganisation then becomes a redirect exercise.

---

What to do next

Look at your own URLs. If they contain a date and your content is evergreen, you have a decision worth thinking about — and the earlier you make it, the cheaper it is.

If they are already post-name and readable, this is one WordPress setting you can stop thinking about entirely.

---

Related guides

• WordPress SEO: what the platform decides for you — where permalinks sit among the defaults
• WordPress categories and tags for SEO — why categories in URLs age badly
• WordPress sitemaps, properly configured — resubmitting after a change
• Why a page is not indexed — when redirects go wrong
• Technical SEO: what actually needs fixing — redirects, canonicals and chains
• Google Search Console reports, read properly — watching a migration
• Speed up WordPress — why redirect chains cost you