Trailing Slash Conventions: The Complete 2026 Guide

A trailing slash is the forward slash at the end of a URL path. /about/ has a trailing slash. /about does not. These two URLs are technically different. Most web servers treat them as separate URLs even when they serve the same content.

Apache and Nginx servers follow a convention. Directories resolve with a trailing slash. Files resolve without one. When you request /about and a directory named "about" exists, Apache redirects to /about/ with a 301. Nginx does the same with the right configuration.

Google's John Mueller confirmed that trailing slash consistency is important. Google treats /page/ and /page as separate URLs if they return separate content. This can cause duplicate content issues. https://developers.google.com/search/blog/2025/06/url-trailing-slash-guidance

Duplicate content. When /page/ and /page both serve identical content, you have two URLs for the same page. Link equity is split. Ranking signals are diluted. Crawl budget is wasted on both versions.

Redirect chains. If your server redirects /page to /page/ and your CMS also redirects /page/ to /page, you create a redirect loop. Google treats loops as errors. Pages in redirect loops do not get indexed.

Canonical confusion. Without a consistent trailing slash policy, canonical tags may point to a version that is being redirected. This wastes the canonical signal. The canonical URL should always match the final rendered URL.

Pick one convention and apply it everywhere. Two standard approaches exist.

Directory-style (trailing slash). Every URL ends with a slash. This treats all pages as directories. It is common on Apache servers. Example: /about/, /blog/post-title/.

File-style (no trailing slash). URLs end without a slash. This treats pages like files. It is common on static sites and modern frameworks. Example: /about, /blog/post-title.

Google does not prefer one convention over the other. The key is consistency. Choose the convention that your server and CMS handle natively and stick with it.

Server-level redirects. If you choose trailing slashes, redirect /page to /page/ with a 301. If you choose no trailing slashes, redirect /page/ to /page. Use Apache mod_rewrite or Nginx rewrite rules. Apply the rule globally to avoid a thousand individual redirects.

CMS settings. WordPress, Shopify, and other CMS platforms have trailing slash settings. WordPress forces trailing slashes by default for permalinks. You can change this with the permalink structure or a plugin. Most modern static site generators like Hugo and Astro strip trailing slashes by default. https://wordpress.org/documentation/article/customize-permalinks/

Canonical tags. Set the canonical URL to the chosen version on every page. If you use no trailing slashes, the canonical should be /about, not /about/. Canonicals reinforce your chosen convention.

Internal links. Check all internal links for trailing slash consistency. A link to /about/ on a site that uses no trailing slashes triggers a redirect on every click. This slows down the user experience.

REST APIs. API endpoints often use no trailing slash by convention. Mixing API URLs with page URLs is acceptable. Apply the slash convention separately to each URL namespace.

Root URL. The root domain example.com typically resolves to example.com/ automatically. Do not force a redirect from example.com to example.com/. Browsers and servers handle the root implicitly.

File extensions. URLs like /page.html should never have a trailing slash. /page.html/ is invalid and may cause errors. Your trailing slash rules should skip URLs with file extensions.

Crawl your site and check every URL for trailing slash consistency. Count how many URLs use each convention. Check for redirect chains between slash and no-slash versions. Verify that canonical tags match the final URL format. Note the gap between current trailing slash usage and a consistent convention. Audit quarterly.