AI AI Tools Guidebook
AI Tool Tutorials

AI International SEO Tutorial: Hreflang, Locale, Currency

Use AI to scope international SEO setup across hreflang, locale signals, and currency formatting in 90 minutes.

Published: Author: AI Productivity Guide Team 🌐 查看中文版本

Expanding a single-locale site to multi-market is mostly mechanical work — but each step has its own footgun. Hreflang gets the most attention; locale signals (date, address, phone) and currency (symbol, decimal, position) eat as many ranking dollars when wrong. This tutorial uses AI to scope a per-locale launch checklist in 90 minutes, covering hreflang, locale formatting, and currency display, with verification commands per item. Output is a markdown plan ready for an engineering ticket.

What this covers

A guided scoping pass for adding one new locale. AI produces three lists: hreflang setup tasks (sitemap, head, x-default), 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 current configuration.

Who this is for

Content sites and product sites planning to launch a second or third locale, SEO managers reviewing an existing multi-locale setup that “kind of works”, and devs handed a vague “add Japanese” ticket without scope. Skip if you are launching a 4th locale on a mature stack — at that point your runbook beats AI’s inference.

When to reach for it

Before any new-locale launch, after a major locale rename (zh to zh-CN), when a market underperforms despite traffic (often a currency or address-format issue), and quarterly as a maintenance audit on existing locales. Pair this with the AI hreflang check tutorial for the deep dive on hreflang specifically.

Before you start

  • Inventory current locales precisely: which lang codes, which URL pattern (subdomain / subdirectory / TLD), which content collection, which CMS. Each shapes the new-locale plan.
  • Decide the lang code for the new locale upfront. Mixing zh and zh-CN across pages is the most common multi-locale bug.
  • Have one live page per existing locale open in browser dev tools. AI’s scope checks need a baseline of what your current setup already does correctly.
  • Identify the target market’s expectations: currency, decimal separator, address format, phone format, paper size, week-start day. List these before scoping.

Step by step

  1. Describe your stack and locales to AI in one paragraph. Include URL pattern, current locales, hreflang strategy, content collection layout, any CMS or i18n library in use.
  2. Ask for three grouped checklists: hreflang setup, locale formatting, currency. Force the grouping — a flat list misses categories.
  3. Ask AI to mark each item P0 (blocks launch), P1 (within 30 days), P2 (nice to have).
  4. Add a verification step per item: curl command, view-source check, regex on rendered HTML, or a screenshot target. Items without verification rot fast.
  5. Walk every P0 item and confirm applicability to your stack. Astro SSG does not need locale middleware; Next.js often does. Remove items that do not apply.
  6. For currency, decide one rule per page type: product pages may need real-time conversion, content pages can use display-only. Conflating these blows up the scope.
  7. Commit the plan as INTL_LAUNCH_<locale>.md. Keep one file per locale launch. Future contributors need the locale-specific context.

First-run exercise

  1. Scope a single locale, not a whole multi-locale rollout. Pick the locale with the clearest market demand.
  2. Run the workflow end to end on that one locale. Time: stack-description prompt 10 min, AI scope 5 min, manual prune 30 min, write-up 30 min, verification commands 15 min. Total: 90 minutes.
  3. Save the conversation. The second locale’s scoping starts from this output as the template, saving an hour next time.
  4. Note any AI hallucinations in a project log — common ones include suggesting hreflang for AMP pages you do not have, or recommending currency conversion APIs that no longer exist.

Quality check

  • Every P0 item has a verification command, URL pattern, or screenshot target. “Verify hreflang exists” is not verifiable; curl -s URL | grep hreflang is.
  • No item references a feature your stack does not support. “Use Next.js middleware for locale” is wrong if you are on Astro.
  • The locale formatting list covers at least: date format, number separator, phone format, address format, week start. Missing any is a soft launch defect.
  • The currency list separates display-only from real-time conversion. They have different verification needs.
  • Hreflang items cross-check the sitemap and the head. Conflict between the two causes Google to ignore both.

How to reuse this workflow

  • Commit one INTL_LAUNCH_<locale>.md per new locale. Keep them in docs/ and reference them from the README.
  • 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. Every time a real bug ships, add it as a constraint to the next scoping prompt.
  • After three locale launches, your prompt becomes more accurate than a generic checklist — invest in refining it.

Stack and current-locale description -> AI produces three grouped checklists (hreflang / locale / currency) -> priority labels (P0 / P1 / P2) -> verification steps per item -> manual prune of inapplicable items -> commit as INTL_LAUNCH_<locale>.md -> quarterly regenerate-and-diff audit.

Common mistakes

  • Treating hreflang as the whole job. It is the easiest to get right and the lowest impact when fixed.
  • 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/YYYY reads as nonsense in most non-US locales — use the platform’s locale-aware formatter.
  • Translating the URL slug for every locale. Some markets prefer English slugs (developer tools often); always-translate is a false consistency.
  • Launching a locale without local search console verification. Without it you cannot tell if the locale is being indexed at all.
  • Conflating locale and language. en-GB and en-US are the same language, different locales — currency and date differ.

FAQ

  • Should subdirectory or subdomain hold a new locale?: Subdirectory by default; subdomain when the locale has a separate team or substantially different content scope.
  • What about ccTLDs?: Strong geo signal, but expensive to maintain. Use only when you have a country-specific business strategy.
  • Do I need a translator or is AI translation enough?: For content site marketing copy, AI is usable as a first pass. For product UI, hire a native reviewer. Conversion correlates with local-feel copy.
  • How do I handle currency conversion?: Display-only conversion at the page level is fine for content. Real-time conversion at checkout requires a live FX feed.
  • How long does a Google indexes a new locale take?: 4-12 weeks for the first crawl to be meaningful. Submit the sitemap and verify the locale in Search Console 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 translationKey to maintain hreflang pairs.

Tags: #SEO #international #hreflang #Tutorial

Related Articles