Astro's i18n fallback URLs broke, fixed in 7.3.0

If you build a Japanese and English site with Astro and configure it to fill in missing English pages with the Japanese ones (fallback), you rarely get the chance to open and check the English URLs one by one. However, there was a bug where, if a page name started with the same letters as a locale code, the English URL itself was generated as a different string. The English counterpart of /ja/japan-office/ became /en/enpan-office/.

Astro 7.3.0 fixed this bug. In this article, we actually build a site configured with Japanese as the default, and cover which versions broke and fixed it, and how to check whether your site is affected.

The bug described in the 7.3.0 changelog

Astro's changelog (CHANGELOG) lists the following fix as #17861 under Patch Changes for 7.3.0.

Fixes i18n fallback routes being generated with a corrupted path when the locale code also appears at the start of a later path segment.

The example combines src/pages/en/enterprise.astro with fallback: { es: 'en' }: the fallback URL was generated as /es/esterprise instead of /es/enterprise. After the fix, only the leading locale segment is rewritten.

According to the npm registry, 7.3.0 was published on September 3, 2026, and the latest version as of September 29, 2026 is 7.3.5.

Results reproduced with a Japanese site setup

We built with the following configuration (case 2) to check whether this also happens on a site with Japanese as the default (September 29, 2026, Linux, Node.js 22; each version of astro installed from the npm registry and built once per version with npx astro build for static output).

// astro.config.mjs（検証ケース2の i18n 設定）
import { defineConfig } from 'astro/config';

export default defineConfig({
  i18n: {
    locales: ['ja', 'en'],
    defaultLocale: 'ja',
    fallback: { en: 'ja' },
    routing: { prefixDefaultLocale: true },
  },
});

fallbackType is unset (defaulting to redirect). We placed index, japan-office, jazz and recruit in src/pages/ja/, and only index in src/pages/en/, so the three pages without English versions became fallback targets.

Only japan-office and jazz, which start with ja, changed to enpan-office and enzz. recruit was not affected. The result was the same in 6.4.8, the final 6.x release.

The dist/en/enpan-office/index.html generated by 7.2.10 was a redirect page like the following.

<title>Redirecting to: /ja/enpan-office/</title>
<meta http-equiv="refresh" content="2;url=/ja/enpan-office/">
<meta name="robots" content="noindex">
<link rel="canonical" href="/ja/enpan-office/">

The redirect target, /ja/enpan-office/, is a page that does not exist anywhere. The canonical also points to that nonexistent URL. And /en/japan-office/, which should have been generated, was not.

What to note in the diagram is that both the English URL and the redirect target change. In 7.3.0, dist/en/japan-office/index.html was generated and redirected to /ja/japan-office/.

When it breaks, and setups that did not break

In case 1, which follows the changelog example (en as the default, fallback: { es: 'en' }, prefixDefaultLocale: true, fallbackType: 'rewrite'), 7.2.10 generated es/esterprise and did not generate /es/enterprise/. 7.3.0 generated es/enterprise. So URL generation broke in the same way even with rewrite chosen instead of redirect.

Case 3 is a setup that does not prefix the default locale (prefixDefaultLocale: false, fallbackType: 'rewrite', Japanese pages directly under src/pages/). In addition to japan-office and jazz, we also added entry, which starts with the English locale code, but the output from 7.2.10 and 7.3.0 was identical, with correct names generated such as en/entry, en/japan-office and en/jazz. It did not break under these conditions.

However, case 3 differs from case 2 in two ways, the presence of the prefix and fallbackType, and we did not isolate which one made the difference. We checked only the static output of three setups, built once per version; we did not test SSR (on-demand rendering), behavior via middleware, the astro dev dev server or other combinations of settings.

Fallback fills the gap while translation catches up, so the longer English pages remain incomplete, the more pages can be affected. We cover how to approach translation in The pitfalls of "cheap AI translation" for multilingual sites.

Checking whether your site is affected

Clients can ask their web development agency, and developers can check in their own repository, in the following order.

1. Check the version you use. Look at the installed version of astro with npm ls astro. If it is 7.3.0 or later, the fix is included.
2. Check your i18n settings. See whether i18n in astro.config.mjs has fallback, and whether routing.prefixDefaultLocale is true. In our tests, the setup that broke had fallback and also prefixed the default locale.
3. Check your page names. Among pages in the fallback source locale, look for those whose second or later segment starts with the fallback target's locale code. In our example, that means japan-office and jazz, which start with ja. In the changelog example, it was enterprise, which starts with en.
4. List the build output. After npm run build, list the pages created in the fallback target directory.

# fallback 先（例: en）に生成されたページの一覧
find dist/en -name index.html | sort

# fallback 元（ja）と並べて、名前の食い違いを探す
diff <(cd dist/ja && find . -name index.html | sort) \
     <(cd dist/en && find . -name index.html | sort)

# 転送先の一覧（redirect の場合）
grep -rho 'content="[0-9]*;url=[^"]*"' dist/en | sort

If dist/en contains names that differ from the originals, such as enpan-office, your site is affected. Pages that exist only in English also show up in the diff, so narrow it down to names starting with en. Also check that no redirect targets point to paths that are not in dist/ja.

What to check before and after upgrading to 7.3.0 or later

To fix it, upgrade astro to 7.3.0 or later. Because the bug also reproduced in 6.4.8, staying on 6.x will not fix it. We discuss the decision, including migrating to 7.0, in Upgrade to Astro 7.0, or rebuild?.

Before upgrading, save the list of dist/en and the list of redirect targets, then after upgrading compare the following three points using the same commands.

• Whether broken names like enpan-office are gone and pages are generated with the same names as the originals, like japan-office
• Whether redirect targets point to pages that actually exist in dist/ja
• Whether the list of unaffected pages (such as recruit in this case) is unchanged

After the fix, the broken URLs are no longer generated. In 7.3.0, en/enpan-office was not output. Check for each site whether the broken URLs appeared in internal links or the sitemap, and decide whether to keep the old URLs using redirects or similar.

7.3.0 also includes other new features and fixes. Read through the changelog sections from 7.3.0 to the latest version, and along with comparing the lists, open the main pages in a preview to check them.

On September 29, 2026, we opened and checked Astro's changelog (the 7.3.0 section of packages/astro/CHANGELOG.md, #17861) and the npm registry's publication information for astro directly, and built astro 6.4.8, 7.0.0, 7.2.10 and 7.3.0 once each on Linux with Node.js 22 to check the static output. Testing was limited to the three cases in this article; we did not test behavior via SSR or middleware, the dev server, other combinations of settings, versions 7.3.1 and later, redirects or 404s on hosting platforms, or how search engines handle them. We did not open the #17861 pull request itself or the Astro blog's 7.3 announcement, and did not rely on them.

For multilingual site maintenance or Astro upgrades, please consult GleamHub.

Sources

• packages/astro/CHANGELOG.md — withastro/astro (GitHub)
• astro — npm registry