Dev.to WebDev πŸ›  Dev πŸ‘ 0 πŸ“– 2 min read

Lessons from moving a multilingual B2B site to Next.js: redirects, hreflang and old shop URLs

When a site changes from an old web shop to a new framework, the visible design is the easy part. The invisible part is what hurts: old URLs, redirects and language versions. Here is what we learned while working on the

When a site changes from an old web shop to a new framework, the visible design is the easy part. The invisible part is what hurts: old URLs, redirects and language versions. Here is what we learned while working on the Wood Architects website, a Lithuanian sauna manufacturer's B2B site built with Next.js and available in 15 languages.

1. Old URLs keep getting links for years

The previous site was a shop with product URLs like /shop/2-5-m-barrel-sauna-terrace. Years later, other sites still link to those addresses. A backlink report showed that these old URLs now redirect to a general category page instead of the matching product category.

Lesson: map every old URL to the closest equivalent page, not to a generic page. A redirect to an unrelated page is treated by search engines almost like a soft 404, and the link value is mostly lost.

In Next.js you can handle this in next.config.js:

module.exports = {
  async redirects() {
    return [
      {
        source: '/shop/:slug*',
        destination: '/en/barrel-saunas',
        permanent: true,
      },
    ];
  },
};

Use permanent: true so the response is a 301 (Next.js sends 308 for permanent redirects, which search engines treat the same way).

2. Avoid redirect chains

We found this path: woodarchitects.eu -> www.woodarchitects.eu -> /en. That is two hops before the user sees a page. Each hop adds latency, and long chains can dilute signals.

Lesson: redirect straight to the final canonical URL in one step. Pick one canonical host (with or without www) and one default language path, then make every variant point there directly.

3. Multilingual sites need hreflang and consistent paths

With 15 languages (/en, /de, /fr, /nl, /da, /sv, /no, /fi, /is, /es, /pt, /pl, /it, /el, /lt), the main risks are:

  • Language versions that do not point to each other with hreflang
  • A missing canonical tag, so search engines pick the wrong version
  • Language switcher links that go to the homepage instead of the same page in another language

Keep the same slug structure across languages where possible, and generate the language switcher links from the current page, not from a static list.

4. Check your backlinks after a migration

A free backlink checker is enough to find this. Look for:

  1. Top linked pages that now return 404 or redirect somewhere unrelated
  2. Redirect chains on your most linked URLs
  3. Links to the non-canonical host (www vs non-www)

Fixing these is often faster and cheaper than building new links.

Checklist

  • [ ] Every old URL has a one-hop 301 to the closest matching page
  • [ ] One canonical host and one default language path
  • [ ] hreflang and canonical on every page
  • [ ] Language switcher keeps the user on the same page
  • [ ] Re-check backlinks and crawl errors a few weeks after launch

If you want to see the finished site, it is at woodarchitects.eu. What was the hardest part of your last migration? Let me know in the comments.

πŸ“° Read the original article on Dev.to WebDev

Originally published by Dev.to WebDev. Aggregated on AIWithGhost for educational purposes β€” full credit and traffic to the original publisher.