Expanding a single-locale site to multiple markets is mostly mechanical work, but each step has its own footgun. Hreflang gets the attention; locale signals (date, number, address, phone) and currency display (symbol, decimal, position) quietly cost you the same conversions when they are wrong. Industry crawls keep finding hreflang errors on roughly three of every four multilingual sites, so getting the fundamentals right already puts you ahead of most competitors. This tutorial uses an AI model (Claude Opus 4.7 or GPT-5.5 both handle it; their 1M-token context as of June 2026 lets you paste your whole <head> and config) to scope one new-locale launch in about 90 minutes. The output is a prioritized markdown plan with a verification command per item, ready to drop into an engineering ticket.
TL;DR
- Feed your stack, current locales, and one live page’s
<head>to the model. Ask for three grouped checklists: hreflang, locale formatting, currency. - Make it tag every item P0 / P1 / P2 and attach a verification step (a
curlline, agrep, or a screenshot target). Items without verification rot. - Hreflang’s two non-negotiables: every page self-references, and every annotation is reciprocal. A missing return tag is the single most common error Google reports.
- Use
en-GBnoten-UK, and lean onIntl.NumberFormatinstead of hardcodingMM/DD/YYYYor a$prefix. - The Search Console International Targeting report was retired in September 2022, so verify hreflang with a crawler (Screaming Frog, Ahrefs, Sitebulb) or
curl, not GSC.
What this covers
A guided scoping pass for adding one new locale. The model produces three lists: hreflang tasks (sitemap, head, x-default, return tags), locale formatting tasks (numbers, dates, phone, address), and currency tasks (display, conversion, checkout). Each item gets a P0 / P1 / P2 label and a verification step. The output is not a generic checklist; it is shaped by your stack and your current configuration, because you give the model your real <head> and URL pattern up front.
Who this is for
Content and product sites planning a second or third locale, SEO managers reviewing a multi-locale setup that “kind of works,” and developers handed a vague “add Japanese” ticket with no scope. Skip this if you are launching a fourth locale on a mature stack; at that point your own runbook beats a model’s inference.
When to reach for it
Before any new-locale launch, after a locale rename (zh to zh-CN), when a market gets traffic but underperforms (often a currency or address-format problem), and quarterly as a maintenance audit. Pair this with the AI hreflang check tutorial when you need the deep dive on hreflang alone.
Before you start
- Inventory current locales precisely: which lang codes, which URL pattern (subdomain / subdirectory / ccTLD), which content collection, which CMS or i18n library. Each shapes the new-locale plan.
- Decide the lang code for the new locale upfront. Mixing
zhandzh-CNacross pages is the most common multi-locale bug, anden-UKis invalid (the ISO 3166-1 code for the United Kingdom isGB, so useen-GB). - Open one live page per existing locale in browser dev tools. The model needs a baseline of what your current
<head>already does correctly. - List the target market’s conventions before scoping: currency, decimal separator, thousands separator, date order, address format, phone format, week-start day.
The prompt and the workflow
- Describe your stack and locales in one paragraph: URL pattern, current locales, hreflang method (head tags vs sitemap), content layout, and any i18n library. Paste the literal
<head>of one live page so the model checks against reality, not assumptions. - Ask for three grouped checklists: hreflang, locale formatting, currency. Force the grouping; a flat list always drops a category.
- Have the model mark each item P0 (blocks launch), P1 (within 30 days), P2 (nice to have).
- Require a verification step per item: a
curlcommand, a view-source check, a regex on rendered HTML, or a screenshot target. “Verify hreflang exists” is not verifiable;curl -s URL | grep -i hreflangis. - Walk every P0 item and confirm it applies to your stack. Astro SSG emits static hreflang and needs no locale middleware; Next.js App Router often does. Delete items that do not apply.
- For currency, set one rule per page type: product pages may need real-time conversion at checkout, content pages can use display-only formatting. Conflating the two blows up the scope.
- Commit the plan as
INTL_LAUNCH_<locale>.md, one file per locale launch. Future contributors need the locale-specific context, and the file becomes your template for the next launch (the second locale’s scoping starts here and saves about an hour).
Budget for the first run: stack-description prompt 10 min, AI scope 5 min, manual prune 30 min, write-up 30 min, verification commands 15 min. Total about 90 minutes. Log any model hallucinations as you go; common ones include suggesting hreflang for AMP pages you do not have, or recommending a currency-conversion API that was shut down.
Hreflang: the three rules the model must encode
These are the rules Google still enforces in its localized-versions documentation (June 2026). Make sure every generated hreflang item respects them.
| Rule | What it means | How to verify |
|---|---|---|
| Self-reference | Each page lists itself among its alternates | curl -s URL | grep -i 'hreflang="en"' returns the page’s own URL |
| Return tags (reciprocal) | If page A points to B, B must point to A, or Google ignores both | Crawl both URLs and confirm symmetric rel="alternate" sets |
| x-default | A fallback for users who match no locale | curl -s URL | grep 'hreflang="x-default"' returns a result |
A missing return tag is the most common hreflang error Google flags. Other reliable killers: protocol mismatch (one side http, the other https), region-only codes, and non-standard variants like es-419, which Google does not accept. All hreflang URLs must be absolute and canonical.
Locale formatting: stop hardcoding, use the platform
The fastest way to make a page feel foreign-built is a US date or a wrong decimal mark. Intl.NumberFormat and Intl.DateTimeFormat cover almost everything from one number. For 123456.789:
| Locale | Currency code | Output |
|---|---|---|
en-US | USD | $123,456.79 |
en-GB | GBP | £123,456.79 |
de-DE | EUR | 123.456,79 € (comma decimal, period grouping, trailing symbol) |
ja-JP | JPY | ￥123,457 (no minor unit, so it rounds) |
new Intl.NumberFormat("de-DE", { style: "currency", currency: "EUR" }).format(123456.789);
// "123.456,79 €"The locale formatting list should cover at least: date order, decimal separator, thousands separator, phone format, address format, and week-start day. Missing any one is a soft launch defect that local users notice even if Google does not.
First-run exercise
- Scope a single locale, not a whole rollout. Pick the locale with the clearest market demand.
- Run the workflow end to end on that one locale within the 90-minute budget above.
- Save the conversation and the committed
INTL_LAUNCH_<locale>.md. They become the template for locale two. - Run a quarterly audit by regenerating the checklist against the same locale and diffing the new output against the committed plan. Maintain a “wrong locale codes” log and feed each real bug back into the next scoping prompt; after three launches your prompt beats any generic checklist.
Quality check
- Every P0 item has a verification command, URL pattern, or screenshot target.
- No item references a feature your stack does not support (“use Next.js middleware for locale” is wrong on Astro).
- The locale formatting list covers date order, decimal separator, thousands separator, phone, address, and week start.
- The currency list separates display-only from real-time conversion; they have different verification needs.
- Hreflang items cross-check the sitemap and the head; a conflict between the two causes Google to ignore both.
Common mistakes
- Treating hreflang as the whole job. It is the easiest part to get right and the lowest-impact once fixed; locale and currency bugs hurt conversion more.
- Skipping currency display tests. A USD-formatted price on a EUR page makes the site look broken to local users.
- Hardcoding date formats.
MM/DD/YYYYreads as nonsense in most non-US locales; use a locale-aware formatter. - Translating the URL slug for every locale. Some markets prefer English slugs (developer tools especially); always-translate is a false consistency.
- Expecting Search Console to validate hreflang. The International Targeting report was retired in September 2022. Verify with a crawler or
curlinstead. - Conflating locale and language.
en-GBanden-USare the same language, different locales; currency and date order differ.
FAQ
- Subdirectory or subdomain for a new locale?: Subdirectory by default; subdomain when the locale has a separate team or a substantially different content scope.
- What about ccTLDs?: Strongest geo signal, but expensive to maintain. Use only when you have a country-specific business strategy.
- Do I need a human translator or is AI translation enough?: For content-site marketing copy, AI is a usable first pass. For product UI, hire a native reviewer. Conversion correlates strongly with local-feel copy.
- How do I check hreflang now that the GSC report is gone?: Crawl with Screaming Frog, Ahrefs, or Sitebulb, all of which report missing return tags, or spot-check with
curl -s URL | grep -i hreflang. - How long until Google indexes a new locale?: Expect 4 to 12 weeks for the first meaningful crawl. Submit the sitemap and confirm the locale appears in the index (a
site:search or the URL Inspection tool) immediately to shorten this. - Should the new locale share the same internal-link graph?: Yes. Mirror the EN graph in the new locale and use
translationKeyto keep hreflang pairs reciprocal.
Related
Tags: #SEO #international #hreflang #Tutorial