A trailing slash makes /page/ different from /page at the HTTP level. Without consistent handling, you have two URLs serving the same content — a classic duplicate content problem.

Code Examples#

Option A: Prefer no trailing slash (common for frameworks like Next.js)#

preferred URL → 200 OK
alternate slash variant → 301 → preferred URL

Option B: Prefer trailing slash (common for WordPress, Apache-based sites)#

preferred slash URL → 200 OK
alternate no-slash variant → 301 → preferred slash URL

Why It Matters#

Inconsistent trailing slashes create duplicate content — Google sees /page and /page/ as two separate URLs competing for the same ranking, splitting PageRank between them.

The Problem#

Both versions appear in Google's index as separate pages, splitting link equity and creating canonicalization ambiguity.

Implementation#

Next.js#

// next.config.js
module.exports = {
  trailingSlash: false,   // 'true' for trailing slash preference
}

Nginx#

# Redirect trailing slash to no-slash
rewrite ^/(.*)/$ /$1 permanent;

Apache#

# Remove trailing slash
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)/$ /$1 [R=301,L]

Canonical Tags#

Regardless of server redirects, add canonical tags pointing to the preferred version:

<!-- On https://example.com/about (preferred) -->
<link rel="canonical" href="https://example.com/about">
 
<!-- If the trailing slash version also serves: -->
<!-- On https://example.com/about/ -->
<link rel="canonical" href="https://example.com/about">

❌ Common Mistakes#

<!-- Canonical points to trailing slash but all internal links omit it -->
<link rel="canonical" href="https://example.com/about/">
<a href="/about">About</a>   <!-- Creates a redirect per navigation -->
 
<!-- Sitemap mixes conventions -->
<loc>https://example.com/about</loc>
<loc>https://example.com/contact/</loc>

Checking Consistency#

curl -I https://example.com/about
curl -I https://example.com/about/

One must return HTTP/1.1 301 with a Location: header pointing to the preferred URL.

Exceptions#

• Staging, utility, login, account, or internal search pages may intentionally use different crawl or index signals if they are not meant to rank.
• Temporary migration states can produce noisy intermediate signals; flag the live production URL pattern, not one-off transition artifacts.
• When redirects, canonicals, robots directives, or indexability signals conflict, fix the strongest final signal first instead of reporting every downstream symptom as a separate blocker.

Standards#

• Use these references as the standard for the final search-facing HTML, metadata, and crawl behavior.
• Check the implementation against Google: Trailing slashes on URLs before treating the rule as satisfied.
• Check the implementation against Google: Consolidate duplicate URLs before treating the rule as satisfied.

Verification#

Automated Checks#

• Inspect rendered HTML and HTTP headers to confirm the expected metadata or crawlability signal is present.
• Test the affected URL with Google Search Console or equivalent tooling where relevant.
• Re-crawl a representative page set after deployment.

Manual Checks#

• Confirm the change does not create conflicting canonical-url, robots, or structured-data signals.