This script is a client-side geo/language router. It only runs on the us language (the default / splash locale). After it fires, the user is sent to /nl, /en, /es, or /de.

What it does

On us pages the layout includes this script in <head> and shows the country-selector splash (logo only; the language links are wrapped in {% if false %}).

  1. IP lookup — fetch("https://ip2c.org/self") returns something like 1;NL;NLD;Netherlands.
  2. Country → language
    • NL → /nl
    • DE → /de
    • ES → /es
    • anything else (US, UK, FR, Googlebot in the US, etc.) → /en
  3. Redirect — window.location.replace("https://{domain}/{lang}?autolang=true")
    replace means the splash URL is not kept in browser history.
  4. Fallback — if the IP call fails, it uses navigator.language (e.g. nl-NL → nl). Unknown browser languages also go to en.
  5. After landing — languagePicker.ts strips ?autolang=true from the address bar and can show a “you’re on the X site” overlay (once per session, at most once per day).

So: guess language from country, then JS-redirect off us. The user does not pick a country first.

SEO-wise (what an SEO person usually means)

Google’s line is: do not geo-block or auto-redirect crawlers/users away from other language versions. Prefer hreflang + a visible language switcher. This file is the geo-redirect; hreflang lives separately in theme/layouts/head/translations.plate.

Why this is milder than a server 302

  • The redirect is JavaScript, not HTTP 301/302. The us HTML is still returned.
  • Bots that do not run JS can stay on us (thin splash: logo, almost no links).
  • Bots that do run JS follow the same rules as users. Googlebot is often seen as a US IP, so it would typically go to /en, not /nl.

Where it can still worry SEO

TopicWhat happens here
x-defaultOn us, you output hreflang="x-default" pointing at the current us URL. That URL then JS-redirects away. x-default is “the fallback locale,” but this page is a router, not a real English homepage.
us vs enhreflang maps us → en-US. The real English site is /en (html lang="en-US"). Two “English/US” signals.
Thin / splash URLus has almost no indexable content (links are disabled). If it gets indexed, it’s a weak page. If Google executes the redirect, it may prefer /en instead.
?autolang=trueFirst hit is /en?autolang=true (or /nl?...). That’s a duplicate URL until history.replaceState runs. Crawlers that don’t run that JS can keep the query string. Canonicals should ignore autolang.
No bot exceptionThere is no Googlebot / AdsBot skip. Same script for everyone.
Country ≠ languageA Dutch speaker in Germany gets German. Fine for “country sites + local vacancies,” weaker if SEO thinks in language, not market.
User choiceOverlay appears after the redirect. Google prefers: user (and crawler) can still reach every locale via links. The picker exists on the real locales, not on this splash.

What is already in good shape

  • Language versions are separate URLs (/nl, /en, …), which Google wants.
  • Alternate/hreflang (and sitemap alternates) are generated for translations.
  • This is not cloaking: same HTML/JS for users and bots.

Typical SEO ask, and a factual answer

“Are we IP-redirecting Google away from country sites?”

No HTTP geo-redirect. HTML for us is served; JS may then send a US-IP crawler to /en. /nl, /de, /es are not chosen by IP unless the crawler’s IP is in those countries. They should still be crawlable if they are linked (hreflang, sitemap, nav). The risk is the us / x-default URL, not hiding NL/DE/ES behind a 302.