slugs in Link section of response headers are wrong

[sahandsn]

Description

I have translated blogs. and I have each locale has its own translated slug.
URLs themselves are ok:

http://localhost:3000/en/blog/healthy-nutrition-for-children-complete-guide-from-birth-to-5-years
https://localhost:3000/fa/blog/تغذیه-سالم-کودک-راهنمای-کامل-از-تولد-تا-۵-سالگی
https://localhost:3000/de/blog/gesunde-ernaehrung-kind-umfassender-leitfaden-von-geburt-bis-5-lebensjahr

---

however, in englsih version, when i open network tab, response headers, link section; i see this:

http://localhost:3000/en/blog/healthy-nutrition-for-children-complete-guide-from-birth-to-5-years; rel="alternate"; hreflang="en", http://localhost:3000/de/blog/healthy-nutrition-for-children-complete-guide-from-birth-to-5-years; rel="alternate"; hreflang="de", http://localhost:3000/healthy-nutrition-for-children-complete-guide-from-birth-to-5-years/%D9%88%D8%A8%D9%84%D8%A7%DA%AF; rel="alternate"; hreflang="fa", http://localhost:3000/healthy-nutrition-for-children-complete-guide-from-birth-to-5-years/%D9%88%D8%A8%D9%84%D8%A7%DA%AF; rel="alternate"; hreflang="x-default"

the issue is that crawlers will mess up in indexing pages because they are using this response as well!

---

in the farsi version, the situation is even worse, because slugs are not even inserted:
link
http://localhost:3000/en/blog/[slug]; rel="alternate"; hreflang="en", http://localhost:3000/de/blog/[slug]; rel="alternate"; hreflang="de", http://localhost:3000/[slug]/%D9%88%D8%A8%D9%84%D8%A7%DA%AF; rel="alternate"; hreflang="fa", http://localhost:3000/[slug]/%D9%88%D8%A8%D9%84%D8%A7%DA%AF; rel="alternate"; hreflang="x-default"

x-middleware-rewrite
/fa/blog/%D8%AA%D8%BA%D8%B0%DB%8C%D9%87-%D8%B3%D8%A7%D9%84%D9%85-%DA%A9%D9%88%D8%AF%DA%A9-%D8%B1%D8%A7%D9%87%D9%86%D9%85%D8%A7%DB%8C-%DA%A9%D8%A7%D9%85%D9%84-%D8%A7%D8%B2-%D8%AA%D9%88%D9%84%D8%AF-%D8%AA%D8%A7-%DB%B5-%D8%B3%D8%A7%D9%84%DA%AF%DB%8C

Verifications

• I've verified that the problem I'm experiencing isn't covered in the docs.
• I've searched for similar, existing issues on GitHub and Stack Overflow.
• I've compared my app to a working example to look for differences.

Mandatory reproduction URL

https://github.com/sahandsn/OsifyAI-Frontend-Test

Reproduction description

repository is linked to a vercel deployment, you can open the single blog and check the response headers in different languages.

"next": "15.5.18",
"next-intl": "^4.12.0",

Expected behaviour

i expected that in both locales, slugs are inserted correctly based on the target locale. and no redirect.rewrite is neeeded.

[SamimSn]

OMG! someone ran into the same issue as me...
i you @amannn to fix this problem as soon as you can :)

[amannn]

Hey, thanks for the detailed report!

I had a look at your reproduction: localized blog slugs come from MDX frontmatter (slug / sharedSlug), resolved at runtime via sharedSlug — that part looks good.

One thing I'd double-check in routing.ts: for fa you have "/[slug]/وبلاگ". Putting [slug] first isn't something RTL requires — URLs stay LTR, and most sites keep the same segment order across locales as far as I know (only the static label and slug text change, e.g. /fa/وبلاگ/[slug]).

The Link response header is a separate code path. Nothing in your app feeds MDX content into pathnames — that object in routing.ts is static templates only.

Two ways to fix this:

1. Compute pathnames dynamically: Since all your content is known locally, you could compute this in module scope based on MDX frontmatter.
2. Provide your own alternate links and locale switcher: More flexible, especially if content moves to a CMS later. The CMS-driven URLs and hreflang & canonicals chapters on learn.next-intl.dev walk through this pattern end-to-end.

Docs: alternate links, localized pathnames.

---

I'll move this to a discussion since it's a usage question.

[sahandsn]

thank for the quick response!

I think for immediate fix, I'll disable automatic alternateLinks from routing.ts because its conflict with sitemap and metadata kills SEO. and since the blog system is implemented for test for eventual CMS integration, computing pathnames dynamically is not an option.

but it made me curious. is link headers needed at all? a quick check with chatGPT says that it is not. because I have spend time to make sure my sitemap and per page metadata are good enough.

I wanted to know your take on this as well. what added benefit it might have re-implementing my own alternate links and locale switcher?

Google says there are three equivalent ways to specify alternate language versions: HTML tags, HTTP Link headers, or XML sitemaps. Google also says there is no search benefit to using all three at once; it is usually better to pick one method and manage it well.