How to add manual hreflang tags in WordPress without a multilingual plugin

A multilingual WordPress site does not always need WPML, Polylang, or another full translation plugin. In one SEO implementation, the site had only two English/Spanish page pairs, and the client specifically wanted to avoid adding another plugin just to manage hreflang tags.

Freshy initially built a lightweight custom hreflang plugin, but the client later chose an even simpler approach. The final implementation used a small wp_head hook in the active child theme, limited to the approved bilingual page pairs. Each mapped page output reciprocal en-US and es-US hreflang tags, an x-default tag pointing to the English page, and the correct page-level HTML language attribute. Freshy verified the output on the development site and confirmed that unrelated pages did not receive the tags.

Issue background

A WordPress site used All in One SEO and included a small number of Spanish-language pages, but no multilingual plugin such as WPML or Polylang.

The source code was not outputting the hreflang tags needed to associate the English and Spanish versions of those pages.

The SEO requirement was specific:

• English and Spanish versions should reference each other.
• x-default should point to the English version.
• Only the approved bilingual pages should receive the tags.
• The site should not take on the overhead of a full multilingual plugin for only a few translated pages.

Early in the project, the team also checked whether the staging environment’s search-engine visibility settings or All in One SEO configuration might explain the missing output. The larger architectural question, however, was how to manage hreflang cleanly without introducing unnecessary multilingual infrastructure.

Diagnosis

The Spanish pages had been created as normal WordPress pages rather than as translations managed by a multilingual plugin.

That meant WordPress had no built-in relationship telling it that one English page and one Spanish page were alternate language versions of the same content.

Freshy considered three approaches:

• Install a full multilingual plugin such as WPML.
• Build a lightweight custom hreflang management plugin.
• Add manual hreflang logic directly to the active child theme for the small number of known page pairs.

A full multilingual plugin was judged unnecessary for the site’s limited use case.

Freshy then built a custom Freshy Hreflang Manager on staging. That plugin provided a default-language setting, page-level hreflang fields, a page-language selector, and automatic x-default behavior.

After reviewing the approach, the client decided not to add another plugin because only two English/Spanish pairs needed the feature.

The implementation therefore changed from a reusable plugin architecture to a tightly scoped manual solution in the child theme.

Resolution steps

The final documented implementation was:

1. Confirm the approved bilingual page pairs. Freshy used the client’s final mapping rather than applying hreflang broadly to every Spanish-language URL.
2. Remove the need for the custom hreflang plugin. The client preferred not to add another plugin for only a few translated pages.
3. Add a small helper function to the active child theme. The function stored the approved English and Spanish page IDs in a simple mapping.
4. Hook the output into wp_head. The code runs only on WordPress pages and checks whether the current page ID belongs to one of the approved pairs.
5. Generate URLs dynamically with get_permalink(). This avoids hard-coding the full domain into every tag.
6. Output the English alternate. Each mapped page receives an en-US hreflang pointing to the English version.
7. Output the Spanish alternate. Each mapped page receives an es-US hreflang pointing to the Spanish version.
8. Set x-default to English. The default alternate always points to the approved English page.
9. Set the page-level HTML language attribute. English pages render with <html lang="en">, while Spanish pages render with <html lang="es">.
10. Verify reciprocal output on all approved pages. Freshy checked the rendered source for each mapped English/Spanish pair.
11. Verify that unrelated pages remain untouched. A non-target page was checked to confirm that no hreflang tags were injected there.

The core output pattern was:

<link rel="alternate" hreflang="en-us" href="ENGLISH_PAGE_URL" />
<link rel="alternate" hreflang="es-us" href="SPANISH_PAGE_URL" />
<link rel="alternate" hreflang="x-default" href="ENGLISH_PAGE_URL" />

The task’s earlier automated article showed es rather than es-US, but the latest implementation comment explicitly documented en-US, es-US, and x-default. This article follows that final verified state.

Final outcome

The site received a lightweight hreflang implementation tailored to its actual multilingual footprint.

Rather than installing a full multilingual platform, Freshy limited the logic to the two approved English/Spanish page pairs. The final setup:

• Outputs reciprocal en-US and es-US hreflang tags.
• Points x-default to the English version.
• Sets the correct page-level HTML lang attribute.
• Leaves unrelated pages unchanged.
• Avoids adding a new plugin solely for four pages.

Freshy verified the final output on the development site. The Asana task was later marked complete, but the source thread does not explicitly document a production deployment, so this article does not claim that the code was pushed live.

The broader lesson is that hreflang architecture should match the size of the multilingual implementation. A site with hundreds of translated pages may benefit from a dedicated multilingual plugin, while a site with only a few fixed bilingual pairs can often use a carefully scoped manual solution with much less overhead.

If your WordPress site has a small number of translated pages and needs correct reciprocal hreflang and x-default tags without adding a full multilingual plugin, contact Freshy. Our WordPress team can map the page relationships and implement the lightest solution that fits the site.