DEV Community: GUSTAVOSIS

How a Trailing Slash Broke SEO Across 72 Pages in My SaaS

GUSTAVOSIS — Thu, 08 Oct 2026 20:31:53 +0000

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:

https://airuncode.com/es/

But parts of our SEO metadata pointed to:

https://airuncode.com/es

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:

https://airuncode.com/es/

But parts of our SEO metadata pointed to:

https://airuncode.com/es

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

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:

https://airuncode.com/es/

But parts of our SEO metadata pointed to:

https://airuncode.com/es

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

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 )

AIRUNCODE 1.5.4 is here and it's on 🔥

GUSTAVOSIS — Mon, 05 Oct 2026 16:49:11 +0000

I've been changing something fundamental in AIRUNCODE.

I don't think the frontier model should do all the work.

Right now we have Claude, GPT, Chinese models, API endpoints, local models, different subscriptions, different context windows and completely different pricing.

But most software treats the model as the product.

I'm trying to make the model replaceable.

In AIRUNCODE, different models can operate inside the same environment and use the same tools. A frontier model can solve the difficult part of a problem, while a smaller or local model continues the workflow instead of burning expensive tokens doing work it is perfectly capable of doing locally.

Basically: don't pay the architect to carry every brick.

This becomes much more interesting when the environment itself is programmable.

I've now connected AIRUNCODE's graphical engine deeply enough that models can build, compile, inspect the result, modify it and compile again.

That's how I think generative software should work.

Not:

prompt → generate demo → congratulations.

But:

build → compile → inspect → correct → rebuild → repeat.

A sample should be something the system can continue working on until it becomes an actual product.

The easiest analogy I have is LEGO.

I don't want to give the model a finished LEGO set and permission to move three pieces.

I want to give it the box, the pieces, the tools and enough understanding of the environment to build what it needs.

And coding is probably only the first environment where I'm testing this idea.

The next thing I want to explore is simulation.

Imagine a robotics lab where thousands of simulated attempts aren't evaluated only by a reward function.

A frontier model can observe a robot performing a complex procedure, understand what it is trying to accomplish, identify where the procedure went wrong and provide corrective supervision.

Not just:

failed → -1
succeeded → +1

But:

you grabbed the correct component, your position was correct, but step 4 happened before the safety verification required in step 3.

That becomes especially interesting for procedural skills where the order, context and rules matter as much as reaching the final state.

Frontier intelligence becomes the teacher.

Smaller models become workers.

Simulation provides experience.

And the environment keeps the knowledge instead of forcing every new model to rediscover everything from zero.

That's the direction I'm exploring with AIRUNCODE.

The model shouldn't own the workflow.

The environment should.

Why I’m building an AI coding runtime that doesn’t depend on one model

GUSTAVOSIS — Mon, 07 Sep 2026 00:02:41 +0000

AI coding tools are getting better very fast, but there’s one architectural decision I don’t really like: most of them are deeply tied to a specific model, provider, or workflow.

That works well while that model is the best option.

But models change constantly.

One month one provider is ahead, then another gets cheaper, local models improve, pricing changes, limits change, and suddenly your whole workflow is attached to a different stack.

That’s the problem I’m trying to solve with Airuncode.

``
The idea is simple:

The runtime should stay stable. The model should be replaceable.

Airuncode runs locally and acts as the execution layer around the agent. The model is just one component of that system.

So instead of rebuilding your workflow around each provider, the runtime handles things like:

project files
terminal access
git
tests
execution
agent orchestration
context
provider switching

You can use cloud models, your own API keys, or local models depending on the task.

I think this matters because developers are going to use multiple models, not one.

Maybe you want a frontier model for architecture, a cheaper model for repetitive work, and a local model when privacy or cost matters.

The workflow shouldn’t have to change every time.

I’m also experimenting with a second idea inside Airuncode called V-CORE.

Instead of asking an AI agent to recreate rendering, physics, terrain, animation, and other low-level systems from scratch, V-CORE gives the agent native capabilities it can build on top of.

That leads to a broader question I’m interested in:

How much of an agent’s capability comes from the model, and how much comes from the runtime and tools around it?

My suspicion is that the runtime matters much more than people currently give it credit for.

Airuncode is already usable, and I’m building it in public:

https://airuncode.com

I’d especially like feedback from people using Cursor, Claude Code, Codex, OpenCode or local models every day.

Do you actually want model independence, or would you rather use a coding agent that is deeply optimized around one provider?