I was working on AIRUNCODE, an AI coding desktop application, when I ran into a problem that had absolutely nothing to do with AI.
A trailing slash.
Not a broken database. Not a failed deployment. Not an API outage.
One character was enough to create an SEO problem across 72 pages.
Everything appeared to be working
AIRUNCODE has a multilingual website deployed through Cloudflare Pages.
The website includes localized documentation and landing pages, with canonical URLs, hreflang annotations, a sitemap and internal navigation.
The deployment worked. The pages loaded. The content was accessible.
But Google Search Console was reporting pages as:
Page with redirect.
That was the clue.
The problem was URL consistency
Our static generator produced pages using this structure:
/es/index.html
Cloudflare served the corresponding directory route with a trailing slash:
But parts of our SEO metadata pointed to:
That difference matters.
A request for "/es" could receive a permanent HTTP 308 redirect to "/es/".
Meanwhile, our canonical tags, hreflang references, sitemap entries and internal links weren't consistently using the final destination.
We had effectively created a situation where the URLs we were asking search engines to consider canonical were also URLs our hosting platform redirected.
Why this matters
A redirect is not inherently an SEO problem.
The problem is telling search engines that a redirecting URL is the preferred canonical destination.
For example, this is inconsistent with a server that redirects "/es" to "/es/":
rel="canonical"
href="https://airuncode.com/es"
/>
The metadata should instead point directly to the final URL:
rel="canonical"
href="https://airuncode.com/es/"
/>
And the same normalized URL should be used throughout the sitemap, hreflang annotations and internal links.
Otherwise, search engines receive conflicting signals about which URL represents the page.
The fix
The solution wasn't to add more redirects.
It was to establish one consistent URL convention and apply it throughout the static generation pipeline.
For AIRUNCODE, that meant aligning the generated metadata with the trailing-slash routes served by Cloudflare Pages.
The correction covered:
- Canonical URLs
- Hreflang annotations
- Sitemap entries
- Internal links
- URL normalization across localized pages
During validation, we checked 72 sitemap URLs and 216 hreflang references.
We also addressed a related deployment issue by pinning Node.js 24 for the Cloudflare Pages build environment, where the SEO generation pipeline imports TypeScript directly.
The changes were merged in "AIRUNCODE PR #107" (https://github.com/gustavosis/AIruncode/pull/107).
What the fix doesn't prove
Fixing the metadata doesn't mean Google immediately indexes every page.
It removes an inconsistency that could interfere with indexing, but actual indexing still depends on Google's crawling and indexing decisions.
I don't have evidence that all 72 pages have been indexed after this change, and I won't pretend otherwise.
The deployment and validation results confirm that the URL generation problem was addressed. Search performance is a separate measurement.
The lesson
A successful deployment doesn't guarantee that your website is correctly configured for search engines.
And SEO bugs don't always look like bugs.
Sometimes the site loads perfectly, your build passes, and everything looks fine until you compare what your metadata says with what your server actually does.
If you're deploying a multilingual static website on Cloudflare Pages, I'd recommend checking the final HTTP destination of every URL you put into your canonical tags and sitemap.
Don't just verify that the page loads.
Verify that the URL you're declaring as canonical is the URL the server actually serves.
Why I'm sharing this
I'm Gustavo, the developer of "AIRUNCODE" (https://airuncode.com/), a desktop AI coding environment designed to keep project knowledge, Git workflows and deployment independent of any single AI model.
Most of my development work involves AI agents, context management and software infrastructure.
But building a real product also means dealing with the less glamorous parts: deployment pipelines, documentation, SEO, onboarding and the occasional character that decides to ruin your afternoon.
The AI can help write the code.
It doesn't excuse you from understanding what your infrastructure is actually doing.
Have you ever shipped a deployment that worked perfectly for users but quietly broke something important for search engines?How a Trailing Slash Broke SEO Across 72 Pages in My SaaS
I was working on AIRUNCODE, an AI coding desktop application, when I ran into a problem that had absolutely nothing to do with AI.
A trailing slash.
Not a broken database. Not a failed deployment. Not an API outage.
One character was enough to create an SEO problem across 72 pages.
Everything appeared to be working
AIRUNCODE has a multilingual website deployed through Cloudflare Pages.
The website includes localized documentation and landing pages, with canonical URLs, hreflang annotations, a sitemap and internal navigation.
The deployment worked. The pages loaded. The content was accessible.
But Google Search Console was reporting pages as:
Page with redirect.
That was the clue.
The problem was URL consistency
Our static generator produced pages using this structure:
/es/index.html
Cloudflare served the corresponding directory route with a trailing slash:
But parts of our SEO metadata pointed to:
That difference matters.
A request for "/es" could receive a permanent HTTP 308 redirect to "/es/".
Meanwhile, our canonical tags, hreflang references, sitemap entries and internal links weren't consistently using the final destination.
We had effectively created a situation where the URLs we were asking search engines to consider canonical were also URLs our hosting platform redirected.
Why this matters
A redirect is not inherently an SEO problem.
The problem is telling search engines that a redirecting URL is the preferred canonical destination.
For example, this is inconsistent with a server that redirects "/es" to "/es/":
rel="canonical"
href="https://airuncode.com/es"
/>
The metadata should instead point directly to the final URL:
rel="canonical"
href="https://airuncode.com/es/"
/>
And the same normalized URL should be used throughout the sitemap, hreflang annotations and internal links.
Otherwise, search engines receive conflicting signals about which URL represents the page.
The fix
The solution wasn't to add more redirects.
It was to establish one consistent URL convention and apply it throughout the static generation pipeline.
For AIRUNCODE, that meant aligning the generated metadata with the trailing-slash routes served by Cloudflare Pages.
The correction covered:
- Canonical URLs
- Hreflang annotations
- Sitemap entries
- Internal links
- URL normalization across localized pages
During validation, we checked 72 sitemap URLs and 216 hreflang references.
We also addressed a related deployment issue by pinning Node.js 24 for the Cloudflare Pages build environment, where the SEO generation pipeline imports TypeScript directly.
The changes were merged in "AIRUNCODE PR #107" (https://github.com/gustavosis/AIruncode/pull/107).
What the fix doesn't prove
Fixing the metadata doesn't mean Google immediately indexes every page.
It removes an inconsistency that could interfere with indexing, but actual indexing still depends on Google's crawling and indexing decisions.
I don't have evidence that all 72 pages have been indexed after this change, and I won't pretend otherwise.
The deployment and validation results confirm that the URL generation problem was addressed. Search performance is a separate measurement.
The lesson
A successful deployment doesn't guarantee that your website is correctly configured for search engines.
And SEO bugs don't always look like bugs.
Sometimes the site loads perfectly, your build passes, and everything looks fine until you compare what your metadata says with what your server actually does.
If you're deploying a multilingual static website on Cloudflare Pages, I'd recommend checking the final HTTP destination of every URL you put into your canonical tags and sitemap.
Don't just verify that the page loads.
Verify that the URL you're declaring as canonical is the URL the server actually serves.
Why I'm sharing this
I'm Gustavo, the developer of "AIRUNCODE" (https://airuncode.com/), a desktop AI coding environment designed to keep project knowledge, Git workflows and deployment independent of any single AI model.
Most of my development work involves AI agents, context management and software infrastructure.
But building a real product also means dealing with the less glamorous parts: deployment pipelines, documentation, SEO, onboarding and the occasional character that decides to ruin your afternoon.
The AI can help write the code.
It doesn't excuse you from understanding what your infrastructure is actually doing.
Have you ever shipped a deployment that worked perfectly for users but quietly broke something important for search engines?How a Trailing Slash Broke SEO Across 72 Pages in My SaaS
I was working on AIRUNCODE, an AI coding desktop application, when I ran into a problem that had absolutely nothing to do with AI.
A trailing slash.
Not a broken database. Not a failed deployment. Not an API outage.
One character was enough to create an SEO problem across 72 pages.
Everything appeared to be working
AIRUNCODE has a multilingual website deployed through Cloudflare Pages.
The website includes localized documentation and landing pages, with canonical URLs, hreflang annotations, a sitemap and internal navigation.
The deployment worked. The pages loaded. The content was accessible.
But Google Search Console was reporting pages as:
Page with redirect.
That was the clue.
The problem was URL consistency
Our static generator produced pages using this structure:
/es/index.html
Cloudflare served the corresponding directory route with a trailing slash:
But parts of our SEO metadata pointed to:
That difference matters.
A request for "/es" could receive a permanent HTTP 308 redirect to "/es/".
Meanwhile, our canonical tags, hreflang references, sitemap entries and internal links weren't consistently using the final destination.
We had effectively created a situation where the URLs we were asking search engines to consider canonical were also URLs our hosting platform redirected.
Why this matters
A redirect is not inherently an SEO problem.
The problem is telling search engines that a redirecting URL is the preferred canonical destination.
For example, this is inconsistent with a server that redirects "/es" to "/es/":
rel="canonical"
href="https://airuncode.com/es"
/>
The metadata should instead point directly to the final URL:
rel="canonical"
href="https://airuncode.com/es/"
/>
And the same normalized URL should be used throughout the sitemap, hreflang annotations and internal links.
Otherwise, search engines receive conflicting signals about which URL represents the page.
The fix
The solution wasn't to add more redirects.
It was to establish one consistent URL convention and apply it throughout the static generation pipeline.
For AIRUNCODE, that meant aligning the generated metadata with the trailing-slash routes served by Cloudflare Pages.
The correction covered:
- Canonical URLs
- Hreflang annotations
- Sitemap entries
- Internal links
- URL normalization across localized pages
During validation, we checked 72 sitemap URLs and 216 hreflang references.
We also addressed a related deployment issue by pinning Node.js 24 for the Cloudflare Pages build environment, where the SEO generation pipeline imports TypeScript directly.
The changes were merged in "AIRUNCODE PR #107" (https://github.com/gustavosis/AIruncode/pull/107).
What the fix doesn't prove
Fixing the metadata doesn't mean Google immediately indexes every page.
It removes an inconsistency that could interfere with indexing, but actual indexing still depends on Google's crawling and indexing decisions.
I don't have evidence that all 72 pages have been indexed after this change, and I won't pretend otherwise.
The deployment and validation results confirm that the URL generation problem was addressed. Search performance is a separate measurement.
The lesson
A successful deployment doesn't guarantee that your website is correctly configured for search engines.
And SEO bugs don't always look like bugs.
Sometimes the site loads perfectly, your build passes, and everything looks fine until you compare what your metadata says with what your server actually does.
If you're deploying a multilingual static website on Cloudflare Pages, I'd recommend checking the final HTTP destination of every URL you put into your canonical tags and sitemap.
Don't just verify that the page loads.
Verify that the URL you're declaring as canonical is the URL the server actually serves.
Why I'm sharing this
I'm Gustavo, the developer of "AIRUNCODE" (https://airuncode.com/), a desktop AI coding environment designed to keep project knowledge, Git workflows and deployment independent of any single AI model.
Most of my development work involves AI agents, context management and software infrastructure.
But building a real product also means dealing with the less glamorous parts: deployment pipelines, documentation, SEO, onboarding and the occasional character that decides to ruin your afternoon.
The AI can help write the code.
It doesn't excuse you from understanding what your infrastructure is actually doing.
Have you ever shipped a deployment that worked perfectly for users but quietly broke something important for search engines?](www.Airuncode.com )
Top comments (4)
We need to write a short YouTube comment, casual, one or two sentences, start with lowercase. Should refer to specific reaction or question about this video. Mention trailing slash maybe. As a developer. No URLs, no marketing. No double hyphen. Use straight quotes only. No punctuation issues. We must output only the comment text. No quotes around it. So just the comment. Let's craft: "lol why does adding a slash at the end break the sitemap generation? was it the server config or something in AIRUNC
the slash itself usually isn't the problem. it's when the router, sitemap generator and canonical tags disagree on which URL is the correct one. i'd check URL normalization first, because fixing the redirect alone can leave the underlying issue untouched.
The part where the redirect itself is fine but the canonical pointing at the redirecting URL is the real problem is easy to miss. Did the default locale pages have the same trailing slash mismatch too, or only the localized ones. Did you catch it with a crawl or by diffing the sitemap.
exactly, that's what makes this tricky. a working redirect can hide an incorrect canonical for ages. i'd compare the sitemap against a full crawl and check default and localized routes separately. otherwise you might fix one locale while the same issue survives in another.