International SEO For Publishers: How To Succeed Across Borders With Codex, Claude Code, ChatGPT, And Hermes Agent

Most publishers pick an international URL structure the same way they pick a CMS theme: they see a big brand do it, assume it must be the right answer, and only discover the cost two years later when hreflang is broken and nobody can explain why the German edition is invisible.

This guide is about doing the opposite. You will hand the research, the audit, and the verification to four AI coding agents, keep the decisions yourself, and end up with a country and language plan you can defend in a budget meeting. The agents do not choose your strategy. They gather evidence, run the checks, and tell you where the evidence disagrees with your assumptions.

What you will finish with

By the end of this workflow you have:

• A written inventory of every country and language combination you actually intend to serve, with the ones you are dropping marked as dropped.
• A URL architecture decision for each combination, with the reason recorded next to it.
• An evidence pack: current Google guidance, live hreflang and canonical checks on your own site, and a list of competitor domains in each target market.
• A verification report that shows the plan is internally consistent before a single new domain or subfolder is built.

Who this is for: publisher SEO leads, growth engineers, and small newsroom teams who need to expand beyond one country and cannot afford to rebuild the URL structure twice.

What you need before starting: read access to your own site or a crawl export, a spreadsheet or Markdown file to hold the plan, and at least one of the four agents installed. You do not need all four. The workflow is designed so each agent can carry the whole job, and the comparison table later in this article tells you which one to pick for which part.

Rough effort: one afternoon for the first pass on a site with two or three markets. Add an hour per additional market.

Definition of done: every country and language combination has a URL pattern, a reason, and a named owner, and the verification report shows no unresolved conflict between your hreflang, canonical, and sitemap signals.

Before you start: the three decisions agents cannot make for you

This is the part most "let the AI do it" guides skip, and it is the reason those projects fail.

An agent can tell you that example.com/de/ is a subfolder and that example.de is a ccTLD. It cannot tell you whether your newsroom has the budget to run a local desk in Berlin, or whether your editorial board will accept that the French edition runs different stories than the English one. Those are business decisions, and if you hand them to a model you will get a confident answer built on nothing.

So decide these three things first, in writing, before you open an agent:

1. Are you serving countries, languages, or both? A UK/US/Australia expansion is a country problem in one language. A US site adding Spanish is a language problem in one country. A global publisher doing both is a two-dimensional problem, and it is much harder. Write down which one you are actually doing.
2. What is your brand strength in each target market? A single generic domain works for publishers with heavy brand search and direct traffic in every market they target. If readers in your target country do not search for your brand by name, a generic domain gives you none of that advantage.
3. How much localization can you genuinely fund? Translation is cheap. A local desk, local sources, and local editorial judgment are not. The gap between those two budgets is where international SEO projects die.

Record the answers as a short memo. You will paste it into every agent prompt, because an agent that does not know your constraints will recommend the most expensive architecture every time.

Give the agents a policy file before you give them a task

All four agents read project context from files. The exact filename differs, but the pattern is the same: you write a short policy document once, and every task inherits it.

A workable policy file for this job looks like this:

# International expansion research policy

## Scope
Markets under evaluation: [list them]
Markets explicitly out of scope: [list them]

## Constraints
- Do not recommend a new ccTLD for a market unless the memo confirms local editorial capacity.
- Treat hreflang as a hint, not a directive, in all recommendations.
- Cite Google Search Central documentation with a URL for every technical claim.

## Output format
1. Market and language inventory (table)
2. URL architecture recommendation per market (table with a reason column)
3. Open questions that require a human decision (bulleted list)

## Boundaries
- Read-only. Do not edit site files, DNS, or CMS content.
- Do not invent traffic, ranking, or revenue numbers.

The boundary section matters more than it looks. Without it, an agent asked to "plan international SEO" will happily start editing hreflang tags in your templates while you are still deciding whether those markets are worth entering.

Build the market and language inventory

This is the first real task, and it is the same job in every agent. You want a table with one row per country and language combination, not one row per country.

Paste this into your agent of choice:

Read the expansion memo in ./expansion-memo.md and the policy in ./AGENTS.md.

Build a market and language inventory for the markets in scope.

For each country and language combination, produce a row with:
- country (ISO 3166-1 alpha-2)
- language (BCP 47, e.g. En-GB, pt-BR)
- whether this is a country problem, a language problem, or both
- whether the same content would be republished in the same language for another country
- whether you can name a local editorial owner, or mark it "no local owner"

Output a Markdown table only. Do not recommend a URL structure yet.
Flag any row where you are guessing. Do not fill gaps with plausible-sounding values.

Expected output: a table with one row per combination, plus a short list of flagged rows.

Quality check: open the flagged list first. If the agent guessed at an editorial owner or invented a language code, its table is not trustworthy yet. Fix the memo and rerun.

Recovery path: if the agent produces a single row per country and collapses language, it has ignored the instruction. Restate the requirement as "one row per country and language pair" and give it one worked example row.

Choose the URL architecture, one market at a time

Now you can ask for a recommendation, and this is where the four agents diverge in usefulness. The underlying logic follows Google's own multi-regional guidance: country-code top-level domains are the strongest country signal, subfolders and subdomains are cheaper but weaker, and parameters are not recommended for this job.

The decision tree that matters is smaller than most articles make it look:

The four URL structures map cleanly onto two axes: how many countries you target and how many languages you publish. Most publisher mistakes come from picking a structure that sits in the wrong cell.

Ask the agent to apply this to your inventory:

Using the inventory you just built, recommend a URL architecture for each row.

Rules:
- Apply the decision table in ./architecture-rules.md.
- For every recommendation, cite the specific row of the inventory it applies to.
- Add a "reason" column that names the constraint from the memo that drove the choice.
- Add a "what breaks if we are wrong" column.

Do not recommend ccTLDs for any market marked "no local owner".
Output: Markdown table plus a short list of rows where no option is clearly correct.

Expected output: one architecture decision per inventory row, each with a reason and a failure mode.

Quality check: read the "what breaks if we are wrong" column. If every row says "minor ranking impact," the agent is not thinking hard enough. A wrong ccTLD decision means abandoning a domain and its accumulated links later.

Recovery path: if the agent recommends ccTLDs everywhere, it has ignored the budget constraint. Point it back at the memo and ask it to re-rank the options by cost.

Why the same-language, multiple-country case deserves its own pass

This is the case that quietly breaks publisher sites, and it is worth making the agent check it specifically.

When you publish the same article in the same language for two countries, you now have two URLs competing for the same queries. Hreflang is supposed to sort that out, but hreflang is a hint, not a directive, and it only works when both pages reference each other. On a news site the timing problem is brutal: the first article gets crawled and indexed within minutes, the second country's version appears later, and until Google recrawls the first article to see the new reciprocal tag, the pairing is not valid. In news, a few hours of invalid hreflang is a few hours of the wrong page ranking.

The red band is the problem window. Article B carries valid hreflang tags, but Google's indexed copy of Article A does not yet, so the pairing is not reciprocal and the tags are not accepted.

Ask your agent to model that sequence explicitly:

Walk through the timeline for this case:
- Article A published for country 1 in language L
- Article B published for country 2 in the same language L, one hour later
- Both are given reciprocal hreflang tags

Describe what Google's index contains at each step, and identify the window where the hreflang pairing is invalid.
Then list the options a publisher has, and mark which ones you would not recommend.

Expected output: a short timeline plus a list of options.

Quality check: the agent should not present hreflang as a guaranteed fix. If it does, it is repeating a common myth and you should send it back to Google's documentation.

Recovery path: if the agent invents crawl timing numbers, ask it for the mechanism rather than a specific number of hours. The mechanism is stable; the exact timing is not.

Run the evidence pass on your own site

Recommendations are cheap. At this point you want the agent to check what your site actually does today, because most international SEO problems are implementation drift rather than strategy errors.

Give the agent read access to a crawl export or your templates, and ask for a single evidence report:

Audit the current site for international signals. Read-only.

Check and report:
1. Every hreflang tag pair and whether it is reciprocal
2. Every hreflang value that does not match a valid BCP 47 language or country code
3. Whether any page has a canonical pointing at a different country's version
4. Whether the HTML lang attribute matches the page's actual language
5. Whether sitemaps list locale variants and whether they agree with the hreflang tags
6. Any country or language subfolder that exists in the URL but is not in the inventory

Output one table per check, with a URL column and a severity column.
Do not propose fixes yet. Report only what you find.

Expected output: six tables, each with URLs and severities.

Quality check: pick two URLs from the hreflang table and verify them by hand in the page source. If the agent's report does not match what you see, the crawl export is stale and every other table is suspect.

Recovery path: if the agent reports zero issues on a site with more than one locale, it probably did not read the templates. Point it at the specific template files or the crawl export path and rerun.

Verify the plan before anyone builds anything

The verification step is where you catch the mistakes that would otherwise cost a rebuild. It is also the step agents are best at, because it is mechanical.

Run this as a final pass:

You are verifying the international plan, not improving it.

For each row of the architecture table:
1. Confirm the inventory row it references exists
2. Confirm the reason cites a constraint that appears in the memo
3. Confirm the recommendation does not contradict any other row
4. Confirm no market marked "no local owner" received a ccTLD recommendation
5. Confirm every technical claim has a source URL

Output a checklist with PASS or FAIL per row, and a final list of rows that need a human decision.
Do not rewrite the plan.

Expected output: a pass/fail checklist plus a short human-decision list.

Quality check: a plan that passes every row on the first run is suspicious. Look for at least one row the agent flagged for human review; if there are none, the constraints in your memo are probably too vague to bite.

Recovery path: if the agent starts "improving" the plan instead of checking it, the verification prompt is too open. Add "Do not rewrite the plan" and rerun.

Which agent to hand which part

All four agents can run every task above. They differ in where they are strong and what they cost you in supervision.

A practical split for a small team: do the inventory and the architecture table in ChatGPT where the conversation is cheap, hand the template audit to Claude Code because it needs to read code, schedule the recurring verification in Codex, and keep Hermes Agent for the research tasks where you want a written approval step before anything changes.

None of these agents should be the one that decides to launch a ccTLD. That is a budget decision with a multi-year tail, and it belongs to a person.

Common failure modes

• Letting the agent pick the architecture before you write the memo. You get the most expensive recommendation every time, because the model has no cost constraint unless you give it one.
• Treating hreflang as a fix rather than a hint. It is a signal Google may or may not act on, and it only works when the pairing is reciprocal and current.
• Publishing the same article in the same language for two countries and hoping. This is the case that most often produces two competing URLs and no clean winner.
• Trusting a zero-issue audit. A clean report on a multi-locale site usually means the agent did not read the right files.
• Skipping the verification pass because the plan looks reasonable. The verification pass is the cheapest part of the whole project and the one that catches the contradictions.

FAQ

Do I need all four agents? No. Each one can run the full workflow. The comparison table is about efficiency, not capability. Pick the one you already have installed and add the others only if a specific step keeps costing you time.

Can an agent implement the hreflang changes for me? It can draft them, and Claude Code or Codex can apply them in a repository. Keep the write step behind an approval gate anyway, because a wrong hreflang or canonical change can deindex a country version quietly.

What if my site already uses subfolders and the agent recommends ccTLDs? That is a legitimate finding, not an instruction to migrate next week. Record it as a long-term direction, price the migration, and keep the current structure working in the meantime.

How current does the Google guidance need to be? Check it at the start of every planning cycle. The multi-regional guidance has been stable in its main points, but the surrounding advice about language switching and geotargeting signals has been updated over time, and an agent working from memory will not tell you when it is out of date.

Is a generic domain ever the right answer for a multilingual publisher? It can work when the audience is in one country but speaks several languages, because translated pages are not duplicates. It gets much weaker once you are targeting several countries and several languages at once.

Author: Dominic Hale, International SEO Specialist Across 18 Markets at Auspia. Dominic writes about multilingual site architecture, regional search behavior, and how growth teams can run localization research with AI agents.