Host & URL Hooks

WordPress Filters relating to the host Weglot uses to build URLs, hreflang tags and the language switcher

Weglot needs to know the public host of the current request to build the language switcher links, the hreflang tags, and to decide whether a link is internal and should be rewritten with the language prefix.

By default it reads the Host header sent by the browser, which is correct on the vast majority of sites. You do not need any of the filters on this page unless your site sits behind a reverse proxy.

When you need these filters

Behind a reverse proxy (a CDN, a load balancer, or a hosting setup that fronts your origin with an internal domain), the origin server does not receive the public domain in the Host header — it receives its own internal hostname. The public domain is carried by the X-Forwarded-Host header instead.

When that happens, WordPress keeps working normally, because home, siteurl and the canonical URLs are stored in the database. But Weglot resolves the host from the request, so you see:

• language switcher links pointing to the internal domain,

• hreflang tags pointing to the internal domain,

• internal absolute links not getting the language prefix.

A typical symptom is a page whose canonical URL is right while the switcher and hreflang are wrong.

On a WordPress multisite, do not try to fix this by editing the domain column of the wp_blogs table. WordPress uses that value to resolve which site the incoming request belongs to, so changing it breaks site resolution and causes a redirect loop.

weglot_use_forwarded_host

Tells Weglot to read the public host from the X-Forwarded-Host header instead of Host.

Available since Weglot 6.3.

Argument	Type	Description
$use_forwarded_host	bool	false by default. Return true to opt in.

Use case

Your site is served on example.com, but the origin receives an internal hostname and the public domain arrives in X-Forwarded-Host.

<?php

add_filter( 'weglot_use_forwarded_host', '__return_true' );

If the header is absent on a given request, Weglot falls back to the Host header, so the filter is safe to leave enabled.

When several proxies are chained, X-Forwarded-Host can contain a comma-separated list such as example.com, internal.host. Weglot keeps the first entry, which is the host the visitor actually requested.

X-Forwarded-Host is a header sent by the client. Only enable this filter if your proxy overwrites it on every incoming request. If the proxy forwards a client-supplied value untouched, a visitor can inject any domain — and if your site uses a page cache, the poisoned links can then be served to everyone else.

weglot_server_host

Forces the host directly, whatever the request headers contain. Use it when no header carries the public domain, or when you prefer not to trust X-Forwarded-Host.

Available since Weglot 6.3.

Argument	Type	Description
$host	string	The host resolved from the request headers

Use case

<?php

add_filter( 'weglot_server_host', function ( $host ) {
    return 'example.com';
} );

Return the host name only — no scheme, no trailing slash, no path.

This filter is applied last, so it overrides weglot_use_forwarded_host. It is the most reliable option when your public domain is a fixed, known value.

weglot_check_link_server_host

Overrides the host used for one specific decision: whether an absolute link found in the page is internal (and must be rewritten with the language prefix) or external (and must be left alone).

This filter is not new — it has existed for several versions and was simply undocumented until now.

Argument	Type	Description
$server_host	string	The host resolved for the current request

In most cases weglot_server_host is what you want, since it covers link rewriting along with the switcher and the hreflang tags. Reach for weglot_check_link_server_host only when you need link rewriting to use a different host from the rest of the page.

<?php

add_filter( 'weglot_check_link_server_host', function ( $server_host ) {
    return 'example.com';
} );