Are WordPress URLs case sensitive?

What core does with a capitalized URL

When a request such as /Espresso-Guide/ arrives, WordPress lowercases the slug part before querying the database, finds the post saved as espresso-guide, and serves it. Its canonical redirect code then checks whether the address needs correcting. That check fixes the host (www or not), stray index.php, doubled slashes and the trailing slash. It does not compare the letter case of the path, so the mixed-case address is answered directly.

Three parts of a WordPress URL behave differently:

The second row surprises people. Rewrite rules compare words like category, tag, author, page and feed exactly as written, so capitalising them breaks the match even though capitalising the slug after them does not.

Is the uppercase version duplicate content?

In principle yes: Google's documentation states that URL paths are case sensitive, so /About-Us/ and /about-us/ are separate URLs that happen to return the same page. In practice WordPress defuses it on single posts and pages. The canonical link in the head is built from the stored permalink, not from the address that was requested:

<link rel="canonical" href="https://example.com/about-us/" />

Whichever casing a crawler arrives on, it is told the lowercase address is the one to index. You might see the capitalized variant in Search Console under "Alternate page with proper canonical tag", which is that system working, as explained in our guide to that status.

Archives are the weak spot. Core prints a canonical tag only on singular content, so a category reached as /category/Coffee/ has none unless an SEO plugin supplies it. Hydrogen SEO outputs canonical URLs for archives as well as posts; see canonical URLs.

Where uppercase URLs come from

Search engines do not invent capitalized addresses. They find them in links:

• internal links typed by hand in menus, buttons or content (/Contact);
• links from other sites, email signatures and printed material;
• campaign URLs built in a spreadsheet;
• imports from an older system whose addresses were mixed case.

The first group is yours to fix. Search your content and menus for capitalized internal links and correct them so every link uses the address in the canonical tag. External ones you cannot edit will keep working, which is the benefit of case-insensitive matching.

Should you force lowercase with a redirect?

It is optional. With correct canonical tags the duplicates are already consolidated, and for most sites that is enough.

A site-wide lowercase redirect is worth adding when Search Console shows many case variants being crawled, or when analytics splits one page across several rows. If you add one, do it at the server and exclude what must keep its case:

• /wp-content/ and /wp-includes/, since file names there can legitimately contain capitals;
• query strings, where values such as tokens and campaign names are case sensitive;
• /wp-admin/ and /wp-json/.

Test a handful of image and PDF links afterwards. A redirect rule that lowercases Menu.PDF on a Linux server sends visitors to a file that does not exist.

For new media, the simplest policy is lowercase file names before upload. WordPress cleans spaces and odd characters from file names but keeps capital letters.