Of all the conversations I have with clients, there is one that comes up surprisingly often: "things are going well in Chile, we want to open Peru, what do we do with the website?". That question, which sounds like a technical detail, is actually the front door to international SEO, and the answer you choose will shape your organic traffic in both countries for years. I know because a big part of my work is helping companies expand between Chile and Peru, and I have seen both movies: sites that were structured well from day one, and sites that had to migrate everything two years later, with the traffic loss that implies.
In this guide I walk you through the three decisions that matter, in the order you need to make them: how to structure the site, how to implement hreflang without breaking anything, and how to validate that it worked. With examples from Chile and Peru, because that is the corridor where I work the most and where the nuances show up best.
What is international SEO and when do you need to think about it?
International SEO is the work of getting each version of your site to rank in the country it belongs to: a user in Lima sees your content for Peru and a user in Santiago sees the Chilean one, each with its own prices, currency and way of speaking.
You need to think about it earlier than you expect. The most expensive mistake I see is treating it as a "when we are big" problem: the company opens operations in the second country, quickly clones the site or, worse, serves both markets with the same pages, and only when Peruvian traffic fails to take off does someone ask why. By then, cleaning things up means migrating URLs, and migrating URLs always has a cost.
The signal that it is time is simple: if you have prices, stock, a team or customers in more than one country, your site should reflect that reality. Google builds its understanding of your company from every available signal, and when those signals say "this brand operates in Chile" but you want to sell in Peru, you are competing at a disadvantage against any local player that actually looks Peruvian.
Country domains, subdomains or subfolders?
This is the structural decision, and it deserves a calm analysis because undoing it is the expensive part. The three classic options:
Country domains (ccTLDs): yourcompany.cl and yourcompany.pe. It is the strongest geographic signal there is, but each domain starts from zero authority. Every link you earned in Chile does nothing for your Peruvian domain. For a large brand with a marketing budget in each country, it works. For everyone else, it splits your equity in two.
Subdomains: cl.yourcompany.com and pe.yourcompany.com. In practice, Google tends to treat them as semi independent sites, so they inherit less authority than you would hope. It is the option I recommend least, because it combines the worst of both worlds: the complexity of running separate sites without the strong geographic signal of a ccTLD.
Subfolders: yourcompany.com/cl/ and yourcompany.com/pe/. All the authority lives in a single domain, every link you earn in any country adds up for all of them, and geographic targeting is handled with hreflang. For most companies expanding across Spanish-speaking countries, this is the option I recommend, and it is the structure I have implemented most often.
An analogy I use a lot: a ccTLD is like incorporating a brand-new company in each country, each with its own credit history starting from scratch. Subfolders are like opening branches of the same company: the accumulated reputation backs all of them.
What if both countries speak Spanish? Do I need separate versions?
This is the question I get asked the most, and the honest answer is: it depends on how much your business differs between countries, not on how much the language does.
If you sell software with the same prices in dollars, the same features and the same pitch in both markets, a single Spanish version can be enough for quite a while. Creating /cl/ and /pe/ with the same text and just swapping the flag generates dozens or hundreds of nearly identical pages competing with each other, and Google will choose for you which one to show in each country (spoiler: it does not always choose well).
If your prices, payment methods, shipping, regulation or vocabulary change between countries, separate versions justify themselves. Think of a real estate site: in Chile people search for "arriendo de departamentos" and in Peru they search for "alquiler de departamentos". Same intent, different words, and a single page cannot naturally carry both in its title. The same happens with local payment systems like Transbank in Chile and Yape in Peru, or with prices in UF versus soles.
My practical rule: start with a single version if your offer is identical, and split once you have at least three real content differences per page (price, vocabulary, offer, regulation). Splitting too early fills the site with duplicate pages, and splitting too late hands the local searches to the competitor who does use the country's words.
How do you implement hreflang without breaking anything?
Hreflang is the tag that tells Google "this page has a sister version for another country". It sounds simple and it is where most implementations fail. My audits keep finding the same three errors, so let's go straight to how to do it right.
First, the pairs go both ways. If the Chilean page declares the Peruvian one as its version for Peru, the Peruvian page has to declare the Chilean one as its version for Chile. If the reference only goes in one direction, Google ignores it entirely. This is by far the most common error: hreflang gets implemented on the new pages and nobody updates the old ones.
Second, every page declares itself. The Chilean version lists Peru and also Chile (itself). A typical set for this corridor looks like this: es-CL pointing to the Chilean URL, es-PE pointing to the Peruvian one, and x-default pointing to the version you want to show the rest of the world.
Third, hreflang is declared between indexable URLs. If the Peruvian version has a noindex, a canonical pointing to another page or a redirect, the pair is invalidated. Again: Google does not complain, it simply ignores the tag, and you find out months later when you notice Lima is being served the Chilean version.
A detail that confuses a lot of people: hreflang only decides which version is shown in each country once your content is already ranking. If the page is not showing up in the results yet, the tag will not push it there; that job still belongs to the content and the site's authority.
What does real localization mean, beyond translation?
Between two Spanish-speaking countries there is no translation step, which makes lazy localization twice as visible. Real localization means reviewing, at minimum:
The search vocabulary: arriendo versus alquiler, polera versus polo, bencina versus gasolina. This is not solved by intuition but by looking at search data per country, because there are cases where the "Chilean" term is also used in Peru and vice versa.
The currency and prices: showing prices in Chilean pesos to Peruvian users is the fastest way to tell them "this site is not for you". And if you work with UF in Chile, that concept simply does not exist in Peru.
The local signals outside your site: local address, a Google Business profile per country, local press and directories. This weighs more every year, and not only for Google: AI assistants build your company's profile from everything they find, and when someone asks "which company can help me with this in Peru", a brand whose mentions only talk about Chile starts the race behind. Entity consistency per country (your company described the same way on your site, on LinkedIn, in the press and even in each market's job postings) is part of modern international SEO, even if it does not show up in the classic checklists.
An illustrative example to size the vocabulary issue: if "alquiler de departamentos lima" concentrates Peruvian demand and your entire site says "arriendo", you can be optimized by the book and still be out of the conversation, simply because your market searches with a different word.
How do I validate it is working in Search Console?
This is where most teams let go of the wheel, and it is exactly where you see whether the implementation paid off. The process I use:
First, filter the performance report by country. Search Console lets you see queries, clicks and impressions from Chile and from Peru separately, and that separate view is the only one that matters on a multi-country site. The combined average hides everything.
Second, check which URLs receive the impressions in each country. If, under the Peru filter, the impressions are going to the /cl/ version, your hreflang is not working and the pairs need an audit. This check takes ten minutes and catches the problem before it costs anyone traffic.
Third, give it time and measure again. Hreflang and structure changes take weeks to settle, not days. My standard is to review at four weeks: impressions per country, each version's share in its own market, and the CTR of queries with local vocabulary. As an illustrative reference, on a site where the Peruvian version captures 30% of Peru's impressions at the starting point, watching that share climb steadily month after month is the sign that the exchange is operating; if it stalls, there are almost always broken pairs or crossed canonicals.
Where do I start tomorrow?
If your company already operates in more than one country, the full diagnosis takes one afternoon and needs no budget: open Search Console, filter by each country where you sell, and write down which version of your site is receiving the impressions there. Then take your five most important pages and check three things: that the hreflang pairs exist in both directions, that none of the declared URLs has a noindex or a canonical pointing elsewhere, and that each version's vocabulary is the country's own (search for yourself using the local word and see who shows up).
With that diagnosis in hand you know which of the three decisions in this guide needs your attention. And if you are still planning the expansion, even better: all of these decisions are far cheaper to make now than when the site already has years of history that would need migrating.