hreflang for small multilingual sites, simply explained

Agencies charge for hreflang as if it were an engineering project. For a business with an English site and four Spanish pages, it is roughly fifteen minutes of work and then you never think about it again.

Here is the whole thing, without the mystique, sourced to Google's own documentation rather than to anybody's opinion.

What does hreflang actually do?

It stops your two language versions from competing with each other.

Google's documentation on localized versions puts the purpose plainly: telling Google about your variations "will help Google Search point users to the most appropriate version of your page by language or region." The same page adds the caveat that matters for a small site: "even without taking action, Google might still find alternate language versions of your page, but it is usually best for you to explicitly indicate your language- or region-specific pages."

So it is a help, not a switch. Google can still show a different version if it thinks that serves the user better. That is normal and not a sign your tags are broken.

Here is the misunderstanding to clear first, because it is nearly universal. hreflang does not tell Google what language your page is in. Google's documentation says so in one sentence: "Google doesn't use hreflang or the HTML lang attribute to detect the language of a page; instead, we use algorithms to determine the language." Its guide to multilingual sites repeats it: "Google uses the visible content of your page to determine its language. We don't use any code-level language information such as lang attributes, or the URL."

That has a practical consequence. If your Spanish page is half English boilerplate with a translated middle, the tag will not rescue it. Google's advice is to use "a single language for content and navigation on each page" and to avoid side-by-side translations. The tag describes a relationship between pages. The page still has to be in the language you claim.

What do the tags look like?

Each page gets a small block in its head section listing every version of itself, including itself.

If you have an English page and a Spanish page, both pages carry the same block. The English page lists the English URL and the Spanish URL. The Spanish page lists the same two. That reciprocity is the part people get wrong, and Google explains why it is enforced: "If two pages don't both point to each other, the tags will be ignored. This is so that someone on another site can't arbitrarily create a tag naming itself as an alternative version of one of your pages."

Three rules cover almost every small-site case, and all three are Google's own:

1. Every page lists itself. Google: "Each language version must list itself as well as all other language versions." 2. Every page lists every other version. A one-way tag is ignored, per the quote above. 3. Use full absolute URLs. Google: alternate URLs "must be fully-qualified, including the transport method," so `https://example.com/foo`, not `//example.com/foo` or `/foo`.

You can also add an x-default entry. Google describes it as the value "used when no other language/region matches the user's browser setting," recommended as a fallback for language selectors and auto-redirecting home pages. On a small bilingual site that is usually your English page.

You can implement the tags in the page head, in HTTP headers, or in your XML sitemap. Google says the three "are equivalent from Google's perspective" and warns that while you can use all three at once, "there's no benefit in Search" and it is harder to manage. Use the head unless you have a reason not to, because it is the easiest to inspect and the easiest to fix.

What are the language codes and where do people get them wrong?

This is where most small-site hreflang breaks, and Google's own syntax page names the trap.

The first code is the language, in ISO 639-1 format. An optional second code is the region, in ISO 3166-1 Alpha 2. Korean is ko, not kr. Japanese is ja, not jp. Chinese is zh, with zh-Hans and zh-Hant for simplified and traditional script. Spanish is es, and es-MX narrows it to Mexico.

Google's warning box states the rule directly: "You can't specify the country code by itself. The first code stands for the language and Google doesn't automatically derive the language from a country code." Its own bad example is Belgium, where `be` is not Belgium at all but the Belarusian language code.

And here is the one that catches Spanish-language sites specifically, which almost nobody selling hreflang will mention. Google states that "only language codes listed in ISO 639-1 and region codes listed in ISO 3166-1 Alpha 2 are supported; other codes that aren't listed in those standards, such as es-419, aren't supported." The es-419 code for Latin American Spanish is a real and widely used standard elsewhere. Google Search does not accept it. If a developer or a translation plugin has written es-419 into your tags, they are being dropped silently, which is the worst kind of failure because nothing appears broken.

Two more common errors, and these are operator observations rather than documented rules. A tag pointing at a URL that redirects, or at a page carrying noindex, has nothing useful to serve, so it wastes the annotation. And adding a region code you do not need narrows your targeting for no reason. If you have one Spanish version serving everyone, use es, not es-US.

Do I even need this?

Often no, and this is the part nobody selling it will tell you.

Google's own definition of when the pages are even in conflict is narrow: "Localized versions of a page are only considered duplicates if the main content of the page remains untranslated." If your Spanish pages are genuinely different content, written for a different customer rather than mirrored from the English, you are not in the situation hreflang was built for.

If you have exactly one language, hreflang does nothing for you. Skip it.

Where it earns its place is when your two versions are close translations of each other on separate URLs, or when you have multiple versions in the same language for different regions. That second case is where hreflang is genuinely load-bearing, and it is rare for a local business.

There is a related mistake worth avoiding whether or not you use the tags. Google's multilingual guidance says to avoid automatically redirecting users from one language version to another based on what you think their language is, and not to use IP analysis to adapt content, because "most, but not all, Google crawls originate from the US" and Googlebot "sends HTTP requests without setting Accept-Language in the request header." A site that serves Spanish to visitors it guesses are Spanish speakers will show Google the English version and nothing else.

One thing hreflang definitely does not touch: your Google Business Profile. That runs on a separate system entirely, and setting your profile up in a second language is a different job with a much larger payoff for most local businesses.

What is this actually worth, and what should it cost?

Price it as the work it is. The arithmetic takes five minutes.

The quote. Say an agency proposes $2,400 for international SEO setup and hreflang implementation on a fourteen-page site with five Spanish pages.

The work. Ten pages carry annotations: five English, five Spanish. Each block lists three entries, the two language versions plus x-default. That is thirty link elements, and they are identical on both members of each pair, so it is five distinct blocks pasted twice. At $2,400, you are paying $80 per line of HTML.

The audit that tells you whether anything is even wrong. Open each of the ten pages and check four things: does it reference itself, does it reference its counterpart, is the counterpart's tag pointing back, and is the language code valid. That is forty checks. On a typical plugin-generated site, say eleven of them fail, usually a missing self-reference on the Spanish pages plus an invalid code. That is 28%derived of your checks failing, and every one of those failures is a one-line fix.

The comparison. Fifteen minutes of your own time, or an hour of a developer's, against $2,400. Then take the difference and put it somewhere with evidence behind it. Primary Business Profile category scored 227 points as the top individual local pack factor in Whitespark's 2026 survey of 47 local search practitioners, and Darren Shaw's study of 1.8 million Google Business Profiles across 4,209 categories, published in Search Engine Land in August 2026, found the exact-match category outranking every adjacent one for almost every category in the dataset. hreflang appears nowhere in any local ranking factor list, because it is not one.

What matters more than hreflang for a local business?

Almost everything else, honestly.

Your profile, your reviews, your photos, and your hours move local rankings far more than any tag. Google's own description of local ranking is "relevance, distance, and popularity," with prominence drawing on "how many websites link to your business and how many reviews you have." Markup is not in that sentence.

Reviews in particular do more work than any technical fix, and a review cadence that has gone quiet will cost you positions no amount of clean markup can recover. Recency of reviews ranks eleventh in the 2026 Whitespark survey and sustained influx rather than bursts ranks fourteenth.

Local links matter too, and the ones available to you are more accessible than most SEO advice suggests. A membership listing, an event sponsorship, a directory maintained by a group you actually belong to. Business associations in your community produce links and referrals at the same time, which is a better return than either alone.

The same goes for showing up in person. Cultural events can be a real acquisition channel and they tend to produce coverage, photos, and mentions that a tag never will.

There is also a structural lesson worth borrowing from a different problem. Separate pages beat one crowded page when the searches are genuinely different, which is the same reason separate pages for happy hour, brunch, and late night can each rank where a single hours page does not.

What to do this week

Open one of your second-language pages and view the source. Search for hreflang. If you find nothing, note it and move on for now.

Check the language codes on any tags you do find. If you see kr, jp, uk or es-419, fix them to ko, ja, en-GB and es.

Confirm reciprocity. Open the matching English page and verify it points back. If it does not, that is your fifteen-minute fix.

Then run the second-language URLs through Search Console and confirm they are indexed at all. An unindexed page cannot benefit from any tag.

If all of that is clean, stop. You are done with hreflang, possibly forever.

Questions about your hreflang setup?

Email me at eric@seod.com with your domain and the second language you publish in. I will check your tags for the reciprocity error, the country-code error and the es-419 error, and tell you in a sentence whether you need hreflang at all. Most of the time the answer is that you do not.

I answer these myself, and I would rather tell you to skip it than sell you fifteen minutes of work as a project.

Or keep reading more on multilingual and community marketing.