The international SEO checklist
Everything to check before, during and after an international launch: URL structure, hreflang, translation review and market-by-market monitoring.
An international SEO checklist covers four phases: deciding your URL structure and target markets, implementing hreflang and sitemaps correctly, translating and localizing content with a human review step, and monitoring each market separately after launch. Skipping the monitoring phase is the most common gap, because most teams stop once the pages go live.
This checklist is the short version of our multilingual SEO guide, which explains the reasoning behind each item in more depth. Use this as a working list, then follow the links where a decision needs more context than a checklist item can carry. It is also the list our technical SEO service works through on every international engagement, in roughly this order.
On this page
What should you decide before anyone builds anything?
Start with what you are actually targeting. A multilingual site serves the same audience in different languages; a multi-regional site serves different countries that may share a language. Many businesses are both, and Google treats the two cases with the same tools but different reasoning [1].
Skip this step and you end up retrofitting it later, which is far more expensive than deciding it up front. A team that builds a single English site for the US, UK and Australia, then later realizes it needs different prices and legal pages per country, is rebuilding its URL structure and re-indexing every page rather than adding a field to a database. The four decisions below take a day or two of discussion. Getting them wrong costs months.
It helps to write the answer down somewhere the whole team can see it, not just decide it in a meeting and move on. A one-paragraph brief — which markets, why, and whether they are language or country targets — saves the developer from guessing and saves the translator from finding out mid-project that a "language" version actually needed three country variants.
Pick languages, countries, or both
Write this down explicitly. It decides whether you need hreflang with a language code alone or a language-region pair, and it decides whether prices, stock and legal terms need to vary per version.
Choose your URL structure
Subfolder, subdomain or country-code domain, each with its own cost and maintenance trade-offs. Decide once, since migrating URL structure later means redirecting and re-indexing everything you have already published.
Do market-specific keyword research
Do not translate your existing keyword list. Local search demand is different, and the literal translation of your best English keyword is frequently not the term people in that market type.
Confirm legal and currency requirements per market
Tax display rules, required disclosures and accepted payment methods vary by country and are easier to build in from the start than to retrofit later.
What goes on the technical setup checklist?
This is the part that breaks silently if it is wrong, because a missing or malformed hreflang tag produces no error message — search engines just show the wrong page to the wrong reader.
That silence is what makes this checklist item different from the others. A translation mistake gets reported by a reader within days. A broken hreflang pair can run for a year showing German visitors your English homepage before anyone thinks to check, because nothing about the site looks broken from the outside — it simply under-performs in one market for reasons nobody investigates. Build the habit of validating hreflang whenever you touch the site's structure, not only once at launch.
Sitemap-based hreflang deserves a special mention here because it fails in a specific, avoidable way. Teams add the annotations correctly at launch, then months later add new pages through a different process that does not update the sitemap, and the new pages simply never get the hreflang treatment the rest of the site has. Whoever owns page creation needs to know this checklist item exists, not just whoever built the original site.
Give every version its own crawlable URL
No swapping language on one URL with cookies or a script. Each version needs an address a crawler can reach directly.
Add hreflang tags in both directions
Every version must link to every other version, including itself. A one-way hreflang tag is treated as unreliable and often ignored [2].
Set x-default correctly
Decide which page shows to a visitor whose language does not match any of your versions. Get the concept straight in [what x-default hreflang means](/blog/x-default-hreflang) before you implement it, since a wrong x-default sends the wrong readers to the wrong page.
Put hreflang in your sitemap for large sites
Above a few hundred URLs, hreflang annotations in the XML sitemap are easier to maintain and validate than tags repeated in every page's head.
Suggest, never force, a language redirect
A banner that offers the right version and lets the visitor choose keeps every version reachable. A forced IP or browser-language redirect can hide your other versions from crawlers entirely [1].
What goes on the content and translation checklist?
Content is where volume meets quality, and it is where most international rollouts either earn trust or lose it.
The temptation on a tight deadline is to translate everything at once and publish it in a single batch, because that is the fastest way to make the market look "done." It is also the pattern most likely to produce pages nobody has actually read in the target language — headings that are technically correct but not how anyone searches, product names left in English by mistake, or a support page that references a policy that does not apply outside the original market. A slower, reviewed rollout of fewer pages beats a fast rollout of unreviewed ones almost every time.
Budget time for this checklist item specifically, separate from the technical work. A developer can finish the hreflang and URL structure in a sprint; a full content translation and review pass for even a modest site takes weeks, and squeezing it into the same timeline as the technical work is where quality gets sacrificed first.
Translate for search demand, not word for word
Titles, headings and even which pages you build should follow local keyword research, not a literal translation of the English version.
Treat machine translation as a first draft only
Run pages through translation software to save time, then have a fluent editor fix terms and tone before anything publishes. [Unedited output at scale is what draws scrutiny](/blog/machine-translation-and-seo), not the translation method itself.
Localize more than the words
Currency, units, date formats, phone number formats and example names all read as foreign when left untranslated, even in an otherwise fluent page.
Publish at a pace your editor can review
A steady stream of reviewed pages beats a single bulk upload that skips review to hit a launch date.
What should be ready before you flip the switch on a new market?
Different page types have different readiness bars. A homepage with a slightly rough translation is recoverable; a checkout page with the wrong currency symbol is not.
Treat readiness as a spectrum rather than a single launch date. Some page types need to be right on day one because a mistake there costs a sale or breaks a legal requirement. Others can ship in a rougher state and improve steadily afterward, because the cost of an early reader seeing an unfinished blog post is low and the cost of delaying the whole launch to perfect it is high.
| Page type | Minimum bar before launch | Can improve after launch |
|---|---|---|
| Homepage and navigation | Fully translated and reviewed, correct hreflang | Copy tone, imagery |
| Product or service pages | Accurate translation, correct currency and units | Extended descriptions, FAQs |
| Checkout and legal pages | Verified by someone fluent in local law and tax rules | Rarely — get this right the first time |
| Blog and resource content | A handful of pillar pages translated and reviewed | Ongoing — this is where volume grows over time |
Launching a market with strong core pages and a thin blog is a normal, sensible sequence. Launching with a translated blog and an unreviewed checkout page is backwards.
What goes on the post-launch monitoring checklist?
The checklist does not end at launch, and this is the phase teams most often drop.
It is easy to see why. Launch has a deadline and a visible outcome, so it gets attention. Monitoring has neither — nothing forces anyone to check a new market's Search Console property next month, and a slow decline in an unwatched market produces no alert, just a quarter of quietly missed opportunity. Put a name and a calendar reminder against each item below before you consider the market launched.
Set up Search Console for the new URLs
Confirm the new version's URLs are indexing and check the international targeting signals it reports, so problems surface within days instead of months [4].
Track rankings and traffic per market separately
A blended, all-markets number hides a struggling market inside strong overall growth. Break out reporting by language or country from day one.
Re-check hreflang after every site change
A template change, a URL migration or a new page type can quietly break hreflang pairs. Re-validate it whenever the site structure changes, not only at launch.
Refresh translated content on the same cadence as the source
A translated page that never gets updated after the English original changes drifts out of date, and readers notice before search engines do.
Should you run this checklist yourself or bring in help?
Either can work. A developer and a fluent local editor can execute every item above with enough time and attention, and plenty of teams do exactly that for a first market or two.
Where teams most often ask for outside help is the judgment calls rather than the mechanical steps — choosing a URL structure under deadline pressure, debugging hreflang that looks correct in the code but is not doing what it should, or deciding which of six candidate markets to launch first with a limited translation budget. Those decisions are hard to get right from a checklist alone, because the correct answer depends on specifics a generic list cannot know: your traffic mix, your existing domain authority, and which markets your sales team can already support. If you are comparing options, the agencies that specialize in this work is a reasonable starting list to work from, and it is worth reading before you commit a budget either way.
Questions people also ask
What's the very first decision on an international SEO checklist?
Whether you are targeting languages, countries, or both, because that decision sets your URL structure. Decide this before a developer builds anything, since changing it later means redirecting and re-indexing every page you have already shipped.
Do I need a separate checklist per market, or one checklist for the whole rollout?
One checklist for the structural decisions — URL pattern, hreflang, sitemap setup — and a repeatable per-market checklist for content, keyword research and monitoring, since those steps happen again for every new language or country you add.
How long does it take to work through this checklist for one new market?
The technical items — hreflang, sitemaps, redirects — usually take a developer a few days once the pattern is decided. Content and translation take longer and scale with your page count; monitoring is ongoing, not a one-time task.
What's the single most common item teams skip?
Monitoring after launch. Most checklists stop at 'pages are live,' but a market with no one watching its Search Console property or its local rankings will drift for months before anyone notices something is wrong.
Should an agency run this checklist, or can an in-house team do it?
An in-house team with a developer and a fluent local editor can work through it. Where teams most often want help is the parts that require judgment calls under time pressure — URL structure, hreflang debugging, and deciding what to launch first.
Sources
- Managing multi-regional and multilingual sites — Google Search Central (checked 23 September 2026)
- Tell Google about localized versions of your page — Google Search Central (checked 23 September 2026)
- Spam policies for Google web search — Google Search Central (checked 23 September 2026)
- Search Console overview — Google Search Central (checked 23 September 2026)
Want a second pair of eyes on your rollout plan?
Book a free 30-minute consultation with Ibrahem and Jeremy. We look at your site while we talk, and you leave with a prioritised plan.
Who wrote this
Jeremy ZavaCo-founder
Leads growth and client partnerships.
Works on: CRO, SEO
Reviewed before publishing by Ibrahem Helal, Co-founder.
- Multilingual SEO: a complete guide for 2026How multilingual SEO works: URL structure, hreflang, translation, keyword research and redirects, with what each decision costs and how to check it is working.
- What is x-default hreflang?x-default is the hreflang value for visitors who match none of your language or country versions — what it means and when your site actually needs one.
- Is machine translation OK for SEO?Machine translation is fine for SEO once a person edits it and you publish at a pace an editor can manage; raw output at scale is what Google's policy targets.
- Best International SEO Agencies (2026)Four agencies — a global network, a UK specialist, and two localization firms — reviewed on their own published pages, plus where we fit, bias disclosed.