Choosing a WordPress Permalink Structure: Post Name vs Date

If you are setting up a new WordPress site, open Settings, then Permalinks, and leave the default Plain option behind. For a blog, a company site or the content section of a small shop, Post name is the simplest choice and the one least likely to cost you later. Dates and categories can go into the URL, but each extra piece makes the address longer and harder to change. The sections called A decision rule and a decision table and Install-day steps let you settle the question in one sitting, whether you run a publication, a store or a client site.

Two live articles pair well with this one: the WordPress SEO settings checklist for the wider setup, and the URL structure and slug best practices for rules that apply to any CMS. If the site runs in two languages, localized URLs and slug translation becomes part of the same decision.

What the documentation means by permanent

The WordPress documentation on permalinks (Opens in a new tab) opens with a definition. Permalinks are the permanent URLs of your posts, pages, categories and other archive pages, and the page says these URLs should never be changed, which is where the name comes from. That one sentence frames every choice on the Settings screen. A permalink structure is not a cosmetic preference; it is the address scheme every future link to your site will carry.

Who holds a copy of your address

The documentation lists four situations where a permalink is used: another blogger links to your article, you share a post on social media, Google indexes the article, and you email a post to a friend. In each case a copy of the address leaves your control. If you rename the address later, those copies still point to the old one.

Why the decision comes before the first post

A structure chosen on day one costs a settings change. A structure changed after hundreds of posts costs a mapping project, because every old address needs a permanent redirect to its new one. That project is a separate topic; the point here is that the cheapest moment to choose well is before publishing.

The three types and the six options

The documentation describes three permalink types and then six options on the Settings screen. The documentation uses English names for them. If your dashboard runs in another language, the labels on screen may look different.

Plain, pretty and almost pretty

Plain, also called Ugly Permalink, looks like example.com/?p=N, where p is a parameter and N is the post or page ID in the database. According to the page, WordPress installs with this setting, it works in every server environment, and it is neither user-friendly nor optimized for search engines.

Pretty permalinks are described as SEO-friendly and attractive. They contain words such as the post title, the category or the tag, so a reader can guess what the page is about from the address. The documentation's two examples are example.com/2012/post-name/ and example.com/2012/12/30/post-name, which means the page itself treats date-based addresses as pretty ones.

Almost pretty permalinks put /index.php in front, as in example.com/index.php/yyyy/mm/dd/post-name/. Apart from that prefix they work like pretty ones. To use them you begin the structure with index.php/.

The options table

One more note from the page matters for support tickets: the hosting provider is expected to have configured the web server for pretty and almost pretty permalinks, and if it has not, you need to contact the provider.

Structure tags and the right ending

In the Custom Structure field you never type the site address. You use one tag or a combination of tags.

The documentation's own example is a title like "This Is A Great Post!" turning into this-is-a-great-post. It says nothing about how accented or non-Latin letters are converted, so check the slug field after typing a title with such letters instead of assuming.

End the structure with an identifier

Among the notes in the Structure Tags section, the documentation says to end your structure with either %post_id% or %postname% so that WordPress can target an individual post for every permalink. The same list of notes says that Almost Pretty permalinks start the structure with index.php/. The documentation gives these notes for customizing Pretty or Almost Pretty permalinks, and its sample is /%year%/%monthnum%/%day%/%postname%/. It does not discuss a structure that ends with %category% or one that is only %year%. Practical suggestion: end with one of the two tags the note names.

Post name: what it gives and where it falls short

Post name reduces the address to the slug. It is short, easy to read aloud and easy to paste into a message. Google's URL structure documentation (Opens in a new tab) recommends readable words over long ID numbers, and a slug made of words satisfies that recommendation directly.

Writing the slug itself

With this structure the address is only as good as the slug. Practical suggestion: before you publish, open the slug field and cut the automatically generated sentence down to the three or four words that name the topic. Google also advises hyphens rather than underscores to separate words, and the slug in the WordPress example already uses hyphens.

What it does not do

Post name does not show where a page sits in the site. The address does not say whether a post belongs to guides, news or case studies. If section context in the URL matters to you, the category option deserves a look. Practical suggestion: give posts that repeat a title pattern, such as monthly reports, distinct slugs from the start, and open each address in a browser before announcing it.

Date-based structures: when they make sense

Day and name and Month and name appear in the Settings screen, and dated addresses appear among the pretty examples. The documentation neither recommends nor forbids them. Google's page gives no rule about dates in a URL either; the only date-related remark concerns dynamically generated calendar links that stretch into the past and future.

Content that belongs to a day

Practical suggestion: for news, announcements and event coverage, where the publication day is part of what the reader needs, a date in the address tells the truth. For content you plan to keep current, such as a buyer's guide, the date becomes a liability. When you refresh the article a year later, the address still shows the old year, and changing the address would contradict the documentation's rule that permalinks should not change.

Moving away from dates later

A site that wants to leave a dated structure has to redirect each old address to a new one. That is a project with its own planning, so treat the choice as nearly final on day one.

The category in the URL: the trade-off

The %category% tag inserts the category slug into the address. The documentation says that when a post has several categories, only one shows in the permalink and the choice is alphabetical. It adds that plugins from the plugin directory can let you choose which category appears.

Where addresses can shift

A rename of a category slug, a move of a post to another category, or a newly added category that sorts earlier in the alphabet can each change the address of a post. That conflicts with the permanence principle.

Conditions for using it

Practical suggestion: choose a category-based structure only when the section scheme is stable, every post has a clear primary category, and slugs are short. Otherwise Post name is safer. The category base and multiple-category behavior are separate questions.

What Google's URL guidance adds

Google's page gives five points that work as tests for any structure you are considering.

The page makes no ranking promise; it describes how to keep URLs understandable for readers and crawlers. Google documentation can change, so check the current page before you rely on a detail.

A decision rule and a decision table

Three questions

Ask three things. Does the content depend on a date? If yes, consider a dated structure; if no, stay with Post name. Will the section scheme look the same in five years? If yes, a category structure is possible; if no, leave it out. Has the hosting provider configured pretty permalinks? If not, follow the documentation and contact the provider before you blame the structure.

Install-day steps

Do these steps on the day you install the site.

• Open Settings, then Permalinks, and move off Plain.
• Pick Post name or the structure that your table row suggests.
• If you type a custom structure, follow the documentation's Structure Tags note and end it with %postname% or %post_id%.
• Keep the default category and tag bases unless you change them before publishing.
• Save, then open one post, one page and one category address in a browser.
• If any of them returns 404, ask the hosting provider about the server configuration.
• Check that the sitemap lists addresses in the new format.

Post-save review questions

• Do the addresses consist of readable words?
• Are slugs lowercase and hyphenated?
• Does the structure end with an identifier?
• Does any address contain a part that could change, such as a category, and do you actually need it?
• Do menus and hand-written links point to the new addresses?

Example scenario: a review blog for accounting software

Example scenario: a three-person team launches a review blog about accounting software, plus a few company pages. The install default, Plain, is still active. One editor wants Day and name because the team plans a weekly roundup. Another wants %category% because reviews will be grouped by product type.

The three questions settle it. The reviews are meant to stay current for years, so the date does not help. The product-type scheme may change when new categories appear, so categories in the address are a risk. The host supports pretty permalinks. The team picks Post name and publishes the weekly roundup under a distinct slug pattern each week. Because the choice is made before the first review goes live, there is nothing to redirect.

The weekly roundup shows the exception clearly: it is the one content type for which a date has meaning, and it can carry that meaning in the title or the body without forcing the date into every address on the site.

Mixed situations: stores, agencies and two-language sites

The same rule does not give the same answer everywhere, so these notes cover the cases where the decision needs extra care.

A blog next to a store

A store plugin can manage its own product and category addresses, and the documentation does not describe plugin settings. Read the plugin's own documentation for product addresses. For blog posts, Post name keeps blog addresses independent of product category renames.

Running several client sites

Agencies benefit from asking the same three questions on every account and keeping the answers in the project notes. When the person who set up the site leaves, the next manager can see why the structure was chosen. Practical suggestion: store a screenshot of the Permalinks screen and the custom structure as plain text next to the answers.

A site in two languages

The documentation does not describe how multilingual plugins handle prefixes or translated slugs. Write the addresses for both languages side by side and check that the structure stays readable in each. Google's page allows words in the audience's language in a URL, so an English post can carry an English slug and a Turkish post a Turkish one.

A site you have just inherited

Note the current setting and custom structure first, then check whether it ends with %postname% or %post_id%. If the addresses work and the structure matches the documentation's note, disliking the structure is not a reason to change it. Practical suggestion: change a live structure only when it causes a real problem, and only with a separate redirect mapping.

Writing down the decision

A permalink choice is easy to forget and hard to reverse, so record it. A short note with five fields is enough for a team of any size.

Where the note should live

Practical suggestion: keep the note with the site's setup documents, not in a chat thread. When someone later proposes a change, the first step is to read the original reasoning next to the documentation's statement that permalinks should not change. If the reasoning no longer holds, for example because the category scheme has settled, a change can be planned with a redirect mapping. If it still holds, the note saves a debate.

Handing the site to someone else

When you hand over a site, include the screenshot of the Permalinks screen, the custom structure as plain text and the reason it was chosen. A new manager who finds the setting switched to Plain by accident can restore the structure in a minute instead of guessing.

Why the note comes before launch

A permalink structure is chosen once and then forgotten. Months later someone asks why addresses look the way they do, and nobody can answer. A one-page decision note stops the debate from restarting every time a new editor, agency or plugin enters the picture.

Example scenario: a language school's course blog

Imagine a language school that publishes level guides, exam tips and teacher interviews. The owner wants short addresses, the marketing assistant wants the course category visible, and the developer worries about future restructuring. Instead of arguing, the three of them list what each content type needs: guides are evergreen, interviews are tied to a season, exam tips are updated every year. The list shows that none of the content depends on its publication date to make sense, which settles the question of whether a date belongs in the address.

Questions the note should answer

Practical suggestion: date the note and store it next to the site documentation. A changed structure later becomes a documented decision, not a surprise.

Reading the options as a reader would

A useful last test is to read an address aloud as a stranger. A Post name address such as example.com/choosing-an-accounting-tool/ tells a stranger what the page is about. A Plain address such as example.com/?p=123 tells them nothing. A dated address tells them when the page was published, and a category address tells them where it sits. Ask which of those four pieces of information your readers need to see in the address, and let the answer, not habit, choose the structure.

The share test

Paste three candidate addresses into a message window and look at them. If an address wraps over several lines, the slug is too long. If it contains a date you would not want to explain a year from now, drop the date. Practical suggestion: run this test on your five most important planned posts before you save the setting.

Mistakes in choosing a structure

Choosing late

Waiting until the site has hundreds of posts turns a settings choice into a redirect project. Decide before the first post.

Renaming categories under a category structure

Because the slug is in the address, a rename changes every post address in that category. Treat category naming as part of the structure decision.

Reading a server problem as a structure problem

If the structure is right but the server is not configured, addresses return 404. The documentation's note applies: contact the host first.

Treating the address as a detail to tidy later

Some teams treat the address as a design detail that can be tidied up at any time. Every published address is a promise to readers who bookmarked it and to pages that link to it, so changing it later always carries a mapping task.

Frequently Asked Questions

Can I change the permalink structure after launch?

You can, but the WordPress documentation says permalinks are permanent and should never be changed. If you change them, every old address needs a permanent redirect to its new address, which is a separate project.

Is Post name better for SEO than a date-based structure?

Google gives no rule about dates in a URL. Practical suggestion: Post name keeps an address from aging on content you plan to update, while a date-based structure can suit a news feed.

Why is the Plain structure not recommended?

The WordPress documentation calls Plain not user-friendly and not optimized for search engines, and Google recommends readable words over long ID numbers.

How should a custom structure end?

In its Structure Tags notes, the documentation says to end the structure with %post_id% or %postname% so WordPress can target one post for every permalink. It gives the note for Pretty and Almost Pretty permalinks.

What if posts return 404 after I save the setting?

The documentation says the hosting provider should have configured the web server for pretty permalinks, and that you should contact the provider if it has not. Start there.

Can slugs contain accented or non-Latin letters?

Google says characters outside ASCII should be percent encoded and allows words from your audience language. The documentation does not describe how WordPress converts such letters, so check the slug field before publishing.

Conclusion

A permalink structure is the one WordPress setting that is expensive to change later. The documentation says permalinks are permanent and should not change, so choose with that in mind. For blogs and company sites, Post name is short, readable and the least exposed to change. Dated structures suit news feeds, and category structures suit a section scheme that will not move. Following the documentation's note, end any custom structure with %postname% or %post_id%, open real addresses after saving, and keep slugs short, lowercase and hyphenated.

If you want help growing the content on that structure with articles that serve readers, take a look at our content writing service.