Technical Hreflang Implementation Guide: English to Spanish (2026)

Step-by-step hreflang implementation for English-to-Spanish sites. HTML tags, XML sitemaps, canonical alignment, and the errors that silently break multilingual SEO — from a Leeds consultant who works this market directly.

TECHNICAL SEOMULTILINGUAL SEO

Jorge Jaroslavsky

6/9/202613 min read

Why English-to-Spanish Hreflang Has Its Own Implementation Rules

Most hreflang guides are written generically. They explain the attribute, show a code snippet, and leave you to figure out the rest. This one is not that guide.

I am writing this specifically for the English-to-Spanish expansion journey because it is the journey I work on directly, in both directions, for UK businesses moving into Spanish markets and for Spanish-speaking businesses entering the UK. That specificity matters more than it might seem. The decisions you face when adding a Spanish version to an English-language site are different from a generic multilingual setup — the language gap is wide, the regional complexity within Spanish is considerable, and the technical choices you make at the start will either support or obstruct your growth for years.

I have a Computer Science degree, twenty years of SEO practice across English and Spanish markets, and I am a native Spanish speaker who has handled hreflang architecture for clients ranging from UK automotive dealer groups to Spanish-market food delivery platforms. What follows is the technical implementation guide I wish existed when I started this work.

If you have not yet read my companion article on choosing the right Spanish locale codes — es, es-ES, es-419, or country-level variants — I would suggest starting there. This article assumes you have already made that strategic decision and are now ready to implement it correctly.

The Minimum You Need to Understand Before Writing a Single Tag

Hreflang does one thing: it tells Google which URL to serve to which audience. When you are moving from English to Spanish, you are telling Google that you have a URL for English speakers and a different URL for Spanish speakers, and you want Google to show each audience the right one.

The attribute sits inside your HTML <head>, your XML sitemap, or your HTTP headers, and it follows a consistent pattern:

The hreflang value uses ISO 639-1 language codes (en, es) and optionally ISO 3166-1 Alpha-2 country codes (GB, ES, MX). Combined, they look like en-GB for English as used in the United Kingdom, or es-ES for Spanish as used in Spain.

Three rules govern the entire system, and breaking any one of them causes silent failure — pages still appear in Google, but in the wrong markets:

Rule one: every page must declare all its alternates, including itself. The English page must reference both the English URL and the Spanish URL. The Spanish page must do the same. If only one side points to the other, Google ignores the relationship entirely.

Rule two: every URL referenced must return a 200 status and be indexable. Hreflang pointing at a redirected URL, a noindex page, or a 404 is invalid. Google will not follow the chain — it simply drops the signal.

Rule three: canonical tags must not contradict hreflang. Each language version must carry a self-referencing canonical. If your Spanish page canonicals back to the English page, you have told Google to ignore the Spanish URL — which directly conflicts with the hreflang tag telling it to serve that URL to Spanish speakers. The result is that Google ignores both signals or picks the one it trusts more, which is usually the canonical.

These three rules account for the overwhelming majority of hreflang failures I find when auditing sites. They are not subtle edge cases. They are basic structural requirements that get missed when implementation is rushed or handed to someone who understood the syntax but not the logic.

The Two Implementation Methods Worth Using

There are three officially supported methods for implementing hreflang: HTML <link> tags in the page <head>, XML sitemap entries, and HTTP headers for non-HTML resources. HTTP headers are only relevant for PDFs or other files served without HTML wrappers. For English-to-Spanish websites, you are choosing between the first two.

HTML Tags: Right for Smaller Sites and Landing Pages

HTML implementation places the hreflang tags directly inside the <head> of each page. For a UK business with one English version and one Spanish version, and a manageable number of pages, this is the most transparent method — you can see exactly what is declared on every page without needing to parse a sitemap.

Here is what the complete implementation looks like for an English-to-Spanish setup targeting UK English and Spain Spanish, on a hypothetical services page:

On the English page (example.com/services/):

</head>

On the Spanish page (example.com/es/servicios/):

<head>

</head>

Notice a few things. The canonical on each page points to itself — not to the English version, not to any other URL. The x-default tag points to the English version, which is the sensible fallback for any user whose language or location does not match a declared hreflang. Each page includes the full set of alternates. The URLs are absolute, including the protocol and domain — relative URLs in hreflang are invalid and will be ignored.

If you are also targeting Latin American Spanish with an es-419 version, you add a third set of tags to every page:

<head>

</head>

Every page in the cluster — the English page, the Spain Spanish page, and the Latin American Spanish page — carries this complete set. Every time.

XML Sitemaps: The Right Choice When You Scale

HTML tags become difficult to maintain at scale. If your site has two hundred pages in English and two hundred corresponding Spanish pages, updating hreflang in templates is manageable. If you have two thousand, or if you are operating on a CMS where modifying <head> output per page requires development work, XML sitemaps are more practical.

The XML sitemap method consolidates all hreflang declarations into one or a few files, which makes auditing straightforward and reduces the risk of inconsistent implementation across large page sets. Google supports this fully — it processes hreflang in sitemaps with the same weight as HTML tags.

The structure requires the XML namespace declaration for XHTML links at the top of the sitemap file, and each <url> block contains the <xhtml:link> alternates alongside the standard <loc> entry:

<?xml version="1.0" encoding="UTF-8"?>

<url>

<loc>https://example.com/services/</loc>

<xhtml:link rel="alternate" hreflang="en-GB"

href="https://example.com/services/"/>

<xhtml:link rel="alternate" hreflang="es-ES"

href="https://example.com/es/servicios/"/>

<xhtml:link rel="alternate" hreflang="x-default"

href="https://example.com/services/"/>

</url>

<url>

<loc>https://example.com/es/servicios/</loc>

<xhtml:link rel="alternate" hreflang="en-GB"

href="https://example.com/services/"/>

<xhtml:link rel="alternate" hreflang="es-ES"

href="https://example.com/es/servicios/"/>

<xhtml:link rel="alternate" hreflang="x-default"

href="https://example.com/services/"/>

</url>

</urlset>

Both the English and Spanish URLs appear in the sitemap, and both carry the complete set of alternates. This is the reciprocal requirement in sitemap form — you cannot declare the relationship from one side only.

One practical point: I recommend creating a separate hreflang sitemap rather than mixing the alternate declarations into your main sitemap. It keeps the file cleaner, makes debugging easier, and means you can submit it independently in Search Console to monitor errors without noise from your standard sitemap.

URL Structure: Decisions That Are Hard to Reverse

Before implementing hreflang, your URL structure for the Spanish version needs to be settled, because changing it later requires a migration with 301 redirects, updated hreflang, and typically a temporary ranking dip. The three common structures for English-to-Spanish sites are subfolders, subdomains, and separate domains.

Subfolders (example.com/es/) consolidate authority on a single domain and are the easiest to manage technically. This is the structure I recommend for most UK businesses adding Spanish as a secondary market. The hreflang implementation is clean, internal linking between language versions is straightforward, and you are not splitting domain authority across properties.

Subdomains (es.example.com) are treated by Google as closely related to the root domain but distinct enough to have their own crawl budget and Search Console property. I use this structure when a client's CMS architecture makes subfolder implementation genuinely difficult, or when the Spanish operation is large enough to warrant its own technical management.

Separate domains (example.es for Spain or example.com.mx for Mexico) provide the strongest geographic signal but also the highest maintenance cost. Authority does not consolidate, each domain needs its own link-building, and managing hreflang across entirely separate domains introduces more surface area for errors. I typically recommend this only when local trust signals justify the investment — a Spain-facing business where a .es ccTLD meaningfully increases conversion rate, for example.

Whatever structure you choose, keep it consistent. Using /es/ for some Spanish pages and /es-es/ for others, or mixing subfolder and subdomain approaches across your site, creates hreflang mapping problems that are disproportionately time-consuming to untangle.

The ISO Code Errors That Silently Break Everything

This is worth a dedicated section because I see these errors in audits regularly, including on sites built by people who clearly understand SEO at a reasonable level.

Hreflang values are case-insensitive in Google's processing, but the correct convention matters for consistency and readability. Language codes in lowercase (en, es), country codes in uppercase (GB, ES, MX). Combined: en-GB, es-ES, es-MX.

The errors that actually cause failures:

Using en-UK instead of en-GB. The ISO 3166-1 country code for the United Kingdom is GB, not UK. UK is not a valid ISO code. Google will not process en-UK as a valid hreflang value. This is an extremely common mistake from UK-based developers who naturally reach for UK as an abbreviation.

Using es-LA for Latin America. LA is the ISO code for Laos. Latin American Spanish is es-419, using the UN M.49 regional code, not a country code. There is no valid two-letter country code that represents Latin America as a region.

Using en-EN or es-SP. These are not valid codes. English for England, if you wanted to be that specific, would be en-GB. Spanish for Spain is es-ES. Double-checking against the ISO 639-1 and ISO 3166-1 Alpha-2 lists before implementing is worth the five minutes it takes.

Mixing up es-es and es-ES in terms of intent. Both are technically processed as the same value, but be consistent in your implementation. A sitemap where half the entries say es-ES and the other half say es-es is not broken, but it is an audit red flag that suggests the implementation was done without a consistent process.

Canonical Tags: The Silent Conflict You Need to Audit

I touched on this in the rules above, but it deserves more depth because it is the failure mode I encounter most often when taking over a multilingual project from a previous consultant or a well-meaning developer.

The scenario looks like this: a developer adds Spanish pages to the site, and to avoid any duplicate content concerns, adds a canonical on each Spanish page pointing to the English equivalent. They have heard that canonical tags prevent duplicate content penalties and are applying the principle correctly in a monolingual context. In a multilingual context, this destroys the hreflang implementation entirely.

A canonical tag on a Spanish page pointing to the English URL tells Google: "this Spanish URL is not the authoritative version — the English URL is." The hreflang tag on the same Spanish page says: "this Spanish URL is the one to serve to Spanish speakers." Google faces a direct contradiction between two signals on the same page and resolves it by trusting the canonical, which is a stronger signal. The result is that the Spanish page is not indexed as an independent URL, and Spanish-speaking users see the English version regardless of what the hreflang says.

The correct implementation is a self-referencing canonical on every Spanish page:

Not:

When I audit a site and find cross-language canonical tags, I know that hreflang has been non-functional regardless of how carefully the alternate tags were implemented. It is one of the first things I check.

x-default: What It Is and When to Use It

The x-default hreflang value handles users whose language or location does not match any declared alternate. It is optional but worth implementing, and the decision about where to point it is more nuanced than it first appears.

For most English-to-Spanish sites, pointing x-default at the English version is the right choice. English is the primary language of the site, it is the version most likely to be useful to an unmatched user, and it is typically the version with the most content depth. A user in Japan, for example, landing on your site without any hreflang match will get your English page rather than a 404 or an incorrect redirect.

There are scenarios where pointing x-default at a language selector page makes more sense — if your site serves a genuinely global audience and neither English nor Spanish is a clear default. I have implemented this for clients with three or more language versions where no single language should be privileged as the fallback. In practice, for UK businesses with an English primary site and a Spanish expansion, the language selector approach adds complexity without meaningful benefit.

What x-default should never point at is a page that auto-redirects users based on IP geolocation. Google explicitly discourages geolocation-based redirects — they prevent crawlers from accessing all language versions and create unpredictable behaviour for users browsing with VPNs or travelling. If you are currently redirecting all Spanish-IP visitors to your Spanish subfolder, that is a separate issue worth addressing, but x-default should point at a stable, accessible URL regardless.

Validating the Implementation: What to Check and How

Once the implementation is live, validation is not optional. Hreflang fails silently — rankings continue, traffic arrives, and the only symptom is that the wrong audiences see the wrong pages. By the time this shows up as a conversion rate anomaly, months may have passed.

Screaming Frog is the most practical tool for hreflang auditing at the page level. Configure it to crawl both your English and Spanish versions, enable hreflang in the configuration, and it will surface missing return tags, incorrect ISO codes, canonicals that conflict with hreflang, and URLs in hreflang that return non-200 status codes. Run this crawl after initial implementation and after any significant site change.

Google Search Console no longer has a dedicated hreflang validation report following the removal of the International Targeting tool in 2022. The most useful approach now is to set up separate Search Console properties for your English and Spanish versions — for example, as separate folder properties for example.com/ and example.com/es/ — and monitor the Coverage and Indexing reports independently. This lets you track whether Spanish pages are being indexed as intended, and flags crawl errors that might indicate hreflang URLs returning non-200 responses.

Manual testing with VPNs remains the most reliable way to verify that Google is actually serving the right version to the right audience. I test UK and Spanish searches using VPN exit nodes in London and Madrid respectively, searching for terms where I expect the English or Spanish version to appear, and verifying the result. This catches the cases where technical implementation is correct but content language detection or other signals are overriding the hreflang — something that happens more often than most implementation guides acknowledge.

One thing I always check specifically for English-to-Spanish implementations: that the Spanish pages are genuinely in Spanish. It sounds obvious, but I have audited sites where Spanish subfolders contained machine-translated content with enough English phrases left in that Google's language detection classified the pages as mixed-language or English, undermining the hreflang signal regardless of what the tags declared.

The Errors I Find Most Frequently When Auditing English-to-Spanish Sites

After two decades of this work, the audit findings repeat. These are the ones I encounter most consistently on English-to-Spanish implementations:

One-directional hreflang. The English page points to the Spanish version, but the Spanish pages do not point back. Often happens when someone adds the Spanish site later and the developer only updates one side. Results in Google ignoring the relationship entirely.

Hreflang on the English pages, nothing on the Spanish pages. Related to the above but subtler — the main site template includes hreflang tags, but the Spanish section is built differently and the tags were never added to that template.

URLs in hreflang that have been redirected. A site migration happened, English URLs changed, hreflang was updated on the live pages but the sitemap still references the old URLs. Old URLs now 301 to new ones. Hreflang pointing at a redirect is invalid.

Spanish pages set to noindex during development and never reverted. This one is particularly painful because everything looks correct from an implementation standpoint — the tags are there, the ISO codes are right, the canonicals are self-referencing — but the pages are not being indexed because a noindex directive from a staging environment was never removed.

Content that is technically Spanish but written for Spain on pages tagged es-419 or es-MX. The technical implementation is fine but the content undermines it. A page tagged es-MX that references "el IVA" (Spain's VAT term) instead of "el IVA" as used in Mexico, or pricing in euros, signals to Google that the page does not actually match the declared audience. From late 2025 onwards, I have seen Google increasingly deprioritise pages where hreflang declarations conflict with content signals, in line with its broader move toward semantic understanding over pure tag compliance.

A Clean Implementation Checklist for English-to-Spanish

Before considering the technical work done, I run through this list for every English-to-Spanish hreflang project:

Every English page declares all Spanish alternates with correct ISO codes, including itself as en-GB (or en for global English). Every Spanish page declares all English and other Spanish alternates, including itself. Every URL in every hreflang tag returns a 200 status. Every URL in every hreflang tag is indexable — no noindex, no disallow in robots.txt. Every Spanish page has a self-referencing canonical. No Spanish page canonicals to the English version. The x-default tag is present and points to a stable, accessible URL. All ISO codes are valid — en-GB not en-UK, es-ES not es-SP, es-419 not es-LA. The hreflang sitemap has been submitted to Search Console. Separate Search Console properties exist for English and Spanish versions. The Spanish content is genuinely written for its declared market — not machine-translated, not full of Iberian Spanish terms on a LatAm-tagged page.

That checklist does not take long to run through, but it catches the errors that silently prevent an otherwise sound multilingual strategy from delivering results.

The Technical Work Is the Foundation, Not the Strategy

I want to close with something I say to clients regularly, because it is easy to lose sight of when you are deep in sitemap XML and ISO code lists.

Correct hreflang implementation is necessary but not sufficient. It tells Google which URL to serve to which audience. It does not make Spanish speakers convert. It does not make your Spanish content trustworthy to someone in Madrid or Mexico City. It does not replace localisation, cultural adaptation, or the commercial decision about which Spanish markets are actually worth your investment.

What I bring to this work, beyond the technical architecture, is twenty years of experience in English and Spanish markets, a native understanding of how Spanish speakers search and what they expect when they arrive on a page, and the ability to audit not just the tags but the entire signal picture — technical implementation, content alignment, canonical structure, and indexing behaviour — as a single coherent system rather than a checklist of isolated items.

The technical hreflang guide above will get your implementation right. Getting the strategy right is a different conversation, and one I am glad to have if your English-to-Spanish expansion is something you are taking seriously.

Get in touch | SEO Localisation Services | About Jorge Jaroslavsky

Back to the Blog

Technical Hreflang Implementation Guide: English to Spanish (2026)

Why English-to-Spanish Hreflang Has Its Own Implementation Rules

The Minimum You Need to Understand Before Writing a Single Tag

The Two Implementation Methods Worth Using

HTML Tags: Right for Smaller Sites and Landing Pages

XML Sitemaps: The Right Choice When You Scale

URL Structure: Decisions That Are Hard to Reverse

The ISO Code Errors That Silently Break Everything

Canonical Tags: The Silent Conflict You Need to Audit

x-default: What It Is and When to Use It

Validating the Implementation: What to Check and How

The Errors I Find Most Frequently When Auditing English-to-Spanish Sites

A Clean Implementation Checklist for English-to-Spanish

The Technical Work Is the Foundation, Not the Strategy

Related blog posts:

Expertise