Multilingual sites with WPML and Polylang
Both plugins run on multilingual WordPress sites. Since Automatic Internal Links 2.0.8, cross-language links are filtered out when the plugin can determine the language of both pages. This page explains exactly when that applies, and what to do where it does not.
If you read an earlier version of this page, it described the cross-language behaviour as an architectural limitation with no workaround. That is no longer accurate.
What the plugin does now
The check runs at render time, immediately before a link would be injected. If the source page and the destination page report different languages, that link is skipped. Nothing is written to your content either way.
The plugin obtains the language through the wpml_element_language_code filter. WPML provides this filter. Where it is available and both languages resolve, links no longer cross the language boundary.
The three cases
A language signal is available and both languages are known. The link is created only if the two languages match. This is the case on a WPML site.
No plugin provides the language signal. The check cannot run. Links are created exactly as they were before 2.0.8, so the older cross-language behaviour applies.
The signal exists but one side's language cannot be resolved. The link is allowed.
That last case is worth stating plainly: the check is fail-open by design. It prevents a link when it can prove the languages differ; it does not block a link merely because it is unsure. The practical consequence is that the filter reduces cross-language links, and reviewing the result is still worthwhile.
Polylang
Polylang has not been tested. Whether it exposes the same filter in a given configuration is not established here. Treat it as unverified rather than as supported or as broken, and verify on your own installation before relying on the filter.
The verification is quick, and it is described below.
How to verify on your own site
The behaviour depends on your stack, so confirm it rather than assuming it.
- Pick a word spelled identically in two of your languages and used as a focus keyword.
stress,format,service,budgetandconfigurationare identical in English and French. - Find a page in language A whose body contains that word, where the keyword's destination page is in language B.
- Run SYNC, then open that page on the front end.
- Read the result carefully, because absence alone proves nothing. A link can also be missing because the keyword is on your exclusion list, because the per-page limit was already reached, because an existing link covers that text, or because the destination is the page itself.
Rule out those causes before concluding. The cleanest reading is a comparison: the same keyword should produce a link towards a same-language destination and none towards a different-language one. If both behave identically, the filter is not the variable.
Conversely, a link that does appear across languages does not prove the filter is off: it may simply be a case where one side's language could not be resolved, which the check deliberately allows.
Do this once per language plugin and per stack. It answers the question for your site better than any general statement can.
Which sites remain exposed
Exposure is proportional to how much spelling your languages share, and it only matters where the filter cannot run.
Higher exposure. English and French, English and Spanish, Spanish and Italian, and any pair with a large shared technical or commercial vocabulary.
Lower exposure. Language pairs with different scripts, such as English and Japanese, Russian or Arabic, where a match is essentially impossible.
Worth checking specifically. Product catalogues. Brand names, model numbers and product references are usually identical across every language version of a store.
Controls that remain useful
These are no longer the only line of defence, but they still help, particularly where the filter cannot run.
Review the activity log
The activity log lists every rule with its keyword and destination. Deleting a rule stops the link being injected at the next render. Note that the log lists rules, not rendered links: a rule can exist while the language filter prevents its link from appearing.
Exclude the shared vocabulary
Adding words your languages spell identically to the keyword exclusion list stops them producing links in every language, which is a real cost. It is worth it for a small set of high-frequency shared words on a stack where the filter cannot run, and rarely worth it otherwise.
Protect the pages that matter most
Per-page exclusion is available in Pro and suits a short list of pages where a wrong link would be most costly.
Sync one language at a time
Restricting a run makes the result easier to read, whether or not the filter is active.
The safety net
Nothing here is destructive. Links are injected at render time and nothing is written into your posts, so an unwanted link is a rule you can delete rather than an edit you have to undo. Deactivating the plugin removes every generated link at once.
What is not affected
Your hreflang tags, language switcher, translated URLs and multilingual plugin configuration are untouched. The focus keyword layer is per-page, so a translated page carries its own keyword and gets its own targeting.
How this was established
By reading version 2.0.11 of the plugin source, where the render-time check and the fail-open behaviour are both explicit, and the 2.0.8 release note that introduced it. It was not executed on a live multilingual installation, which is why the verification procedure above matters.
Read next
- Requirements and compatibility — the full limitation list
- Controlling what gets linked — the four levels of exclusion
- Running sync — the activity log and the cache
- Multilingual case study — the workflow end to end