Netlify’s Pretty URLs feature treats /about and /about/ as the same path automatically, which means you cannot use a redirect rule to add or remove a trailing slash; a rule like /page/ to /page as a 301 redirects a path to itself and produces an infinite loop the browser eventually kills with ERR_TOO_MANY_REDIRECTS. The fix is not a smarter redirect rule, it is understanding that Netlify already normalizes this for you, and any framework-level trailing-slash setting needs to agree with that normalization instead of fighting it.
Netlify’s own docs are precise about this and get missed anyway, because the instinct when you see inconsistent trailing slashes is to write a redirect rule, and that instinct is exactly what causes the loop. The forum is full of the same thread: my trailing slash redirect isn’t working, followed by now it’s an infinite loop. Here is the mechanism, not just the symptom.
Table of contents
- What Pretty URLs actually does
- The exact rule that causes the loop
- Where the real trailing-slash problem usually is
- Framework settings that need to agree
- Canonical URLs and the SEO angle
- What to actually check
- How this fits the rest of the stack
- FAQ
What Pretty URLs actually does
When Pretty URLs is enabled, the default for most site types, Netlify forwards /about to /about/ internally and rewrites .html file paths like /about.html to /about/, and it matches redirect rules to a path regardless of whether the rule or the request includes the trailing slash.
The practical effect: /blog/post and /blog/post/ are treated as the same route for matching purposes. This is meant to remove exactly the ambiguity that causes the redirect loop below, and it works, right up until someone writes a rule assuming Netlify does not already handle it.
The exact rule that causes the loop
Netlify’s docs give this example directly as the failure case.
# This rule will cause an infinite redirect
# because the paths are effectively the same
/blog/remove-my-slashes/ /blog/remove-my-slashes 301!Because Pretty URLs already treats both sides of that rule as the same path, the redirect target matches the redirect source, Netlify redirects the result to itself, and the loop repeats until the browser gives up. This is the single most common trailing-slash bug reported on Netlify’s support forum, and it always traces back to a rule of this shape.
The rule looks reasonable on paper; the mistake is assuming a _redirects or netlify.toml rule can force a slash on or off, when Netlify’s own normalization has already made the two forms equivalent before your rule is even evaluated.
You can see the loop directly without waiting for a browser to give up. curl -I https://example.com/blog/remove-my-slashes/ against a site with that rule returns a 301 pointing right back at the same path, one hop at a time, which is a faster way to confirm the cause than reading the browser’s own too-many-redirects error page.
Where the real trailing-slash problem usually is
If URLs are inconsistent in practice, the cause is rarely Netlify’s routing and almost always the framework generating links: a static site generator emitting one link form in one template and another in a different template, or a single-page app’s router configured for one form while the build output uses the other.
Fix it at the source. Pick one form, trailing slash or not, set the framework’s own trailing-slash option to match, and regenerate internal links consistently, rather than trying to paper over inconsistent output with a Netlify redirect rule that cannot actually change the slash.
Framework settings that need to agree
- Static site generators like Astro, Hugo and Eleventy typically have a trailingSlash config option; set it once and let every generated link follow it.
- Single-page app routers should use the same convention as the build output, since a mismatch here causes broken deep links even without touching Netlify at all.
- next export with static export defaults to no trailing slash unless trailingSlash: true is set in next.config.js, which is the version worth checking if a Next.js static export feels inconsistent on Netlify specifically.
None of these require a Netlify redirect rule. They require the build output to be internally consistent, which Netlify’s Pretty URLs then serves correctly either way.
Canonical URLs and the SEO angle
Search engines treat /page and /page/ as different URLs unless told otherwise, so pick one canonical form and use it everywhere: the canonical link tag, internal links, and your sitemap should all agree, even though Netlify itself will serve either form correctly. This is a content-and-template consistency issue, not a hosting configuration one.
The safest default is to match whatever your framework already generates by default, since fighting that default with redirects or canonical overrides on every page is more maintenance than it is worth for the marginal SEO difference.
Query strings add one more wrinkle worth knowing: Netlify’s Pretty URL matching applies to the path, not the query string, so /search?q=test and /search/?q=test are also treated as equivalent for redirect purposes, but a canonical tag still needs to decide, per page, whether the query string is part of the canonical URL at all. For most sites the canonical form drops tracking parameters and keeps only the ones that change the actual content shown.
What to actually check
If you are seeing a trailing-slash redirect loop right now, delete the rule that tries to add or remove the slash; Netlify does not need it and the rule is the loop’s cause. If URLs are simply inconsistent across the site, fix the framework’s trailing-slash setting and regenerate the build, and confirm the canonical tag and sitemap match the same convention.
A static host that builds directly from your repository, like RunxBuild, handles this the same way: redirects and rewrites are for changing where a path leads, not for adding or stripping a trailing slash the platform already normalizes. See redirects and rewrites on RunxBuild for the rule types actually meant for this kind of config.
How this fits the rest of the stack
Trailing-slash bugs are one of the smaller reasons to look at how a static site is hosted, but they are a good proxy for how much of this configuration you want to hand-manage versus have handled by the platform. See what redirects, rewrites and domain handling look like together in the RunxBuild hosting calculator and static sites on RunxBuild, and the dashboard is where a repository connects if you want to compare the setup directly.
Useful related references:
- Netlify Redirects: The Rules, the Order, and the Portable Parts
- Netlify and SEO: The Platform Settings That Actually Affect Rankings
- Netlify’s CDN: How the Edge Network Actually Serves a Site, What It Caches, and What It Costs When Traffic Arrives
- Redirects on RunxBuild
FAQ
Why does my Netlify redirect for trailing slashes cause an infinite loop?
Because Netlify’s Pretty URLs already treats a path with and without a trailing slash as the same route. A rule that redirects one form to the other redirects a path to itself, which Netlify then redirects again, looping until the browser stops with ERR_TOO_MANY_REDIRECTS.
Should URLs have a trailing slash?
Either is fine as long as it is consistent. Pick one form, set your framework’s trailing-slash option to match, and make sure internal links, the canonical tag, and the sitemap all agree with the same convention.
How do I force a trailing slash on Netlify?
You do not need to; Netlify already normalizes both forms to the same path through Pretty URLs. Fix inconsistent URLs at the framework level, in the static site generator’s trailing-slash setting, rather than with a redirect rule that Netlify’s own docs warn causes a loop.
What is Netlify’s Pretty URLs feature?
The default behavior where /about and /about/ are treated as the same path, and .html file paths like /about.html are rewritten to /about/. It removes the ambiguity that a manual trailing-slash redirect rule would otherwise try, and fail, to fix.
Why are my internal links inconsistent with or without a trailing slash?
Almost always the site generator or router, not Netlify. Different templates or routes emitting links in different forms produces this; setting the trailing-slash option once in the framework’s config and rebuilding fixes it at the source.