Hreflang WordPress Multisito: Guida Implementazione SEO

Juan Camilo Auriti

Perché hreflang è critico nel multisito WordPress

L’implementazione corretta di hreflang in un ambiente WordPress multisito è uno degli aspetti più sottovalutati nella gestione di siti internazionali. Google usa questi tag per capire quale versione linguistica di una pagina mostrare nei risultati di ricerca, e un errore può causare penalizzazioni o confusione tra versioni.

In un network multisito, dove ogni subsito rappresenta una lingua o un mercato geografico, hreflang diventa essenziale per:

Evitare contenuti duplicati tra versioni linguistiche
Indirizzare gli utenti alla versione corretta del sito
Consolidare i segnali SEO tra le diverse versioni
Migliorare l’esperienza utente internazionale

Secondo i dati di Search Console di Google, circa il 38% dei siti multilingua presenta errori di implementazione hreflang che compromettono il posizionamento organico.

Architettura multisito e strategie hreflang

Prima di implementare hreflang, è fondamentale definire la struttura del network multisito. Le tre architetture principali sono:

Sottodomini per lingua

Struttura: it.example.com, en.example.com, de.example.com

Questa è la configurazione più comune in WordPress multisito e offre vantaggi in termini di:

Isolamento completo tra versioni linguistiche
Gestione separata di analytics e Search Console
Possibilità di hosting geograficamente distribuito
Configurazione DNS semplificata

Sottocartelle per lingua

Struttura: example.com/it/, example.com/en/, example.com/de/

Meno comune nel multisito nativo WordPress, richiede configurazione avanzata con domain mapping. Vantaggi:

Consolidamento dell’autorità di dominio
Gestione certificati SSL semplificata
Preferito da Google per segnali di ranking consolidati

Domini separati per mercato

Struttura: example.it, example.co.uk, example.de

Ideale per targeting geografico forte, ma più complesso da gestire in multisito.

Implementazione tecnica di hreflang

L’implementazione di hreflang su WordPress multisito richiede un approccio sistemico. Esistono tre metodi principali, ciascuno con pro e contro specifici.

Metodo 1: Header HTTP

L’implementazione via header HTTP è la più pulita e performante. Richiede l’aggiunta al file functions.php del tema o in un plugin custom:

function add_hreflang_headers() {
    if (is_singular()) {
        $sites = array(
            1 => array('lang' => 'it', 'url' => 'https://it.example.com'),
            2 => array('lang' => 'en', 'url' => 'https://en.example.com'),
            3 => array('lang' => 'de', 'url' => 'https://de.example.com')
        );
        
        $current_post_id = get_the_ID();
        $links = array();
        
        foreach ($sites as $site_id => $site_data) {
            switch_to_blog($site_id);
            $translated_post = get_post($current_post_id);
            if ($translated_post && $translated_post->post_status === 'publish') {
                $permalink = get_permalink($translated_post->ID);
                header('Link: <' . $permalink . '>; rel="alternate"; hreflang="' . $site_data['lang'] . '"', false);
            }
            restore_current_blog();
        }
    }
}
add_action('wp', 'add_hreflang_headers');

Questo approccio richiede che i post abbiano ID corrispondenti tra i vari subsiti, il che funziona bene con strategie di sincronizzazione centralizzata.

Metodo 2: Tag HTML nel head

Più comune e supportato dalla maggior parte dei plugin SEO. L’implementazione avviene tramite hook wp_head:

function add_hreflang_tags() {
    if (!is_singular()) return;
    
    $current_site = get_current_blog_id();
    $current_post = get_the_ID();
    
    // Mappa delle relazioni tra subsiti
    $site_map = array(
        'it' => 1,
        'en' => 2,
        'de' => 3,
        'fr' => 4
    );
    
    foreach ($site_map as $lang => $site_id) {
        switch_to_blog($site_id);
        
        // Cerca post correlato (via meta o ID)
        $translated_id = get_post_meta($current_post, '_translated_post_' . $lang, true);
        if (!$translated_id) $translated_id = $current_post;
        
        $translated_post = get_post($translated_id);
        if ($translated_post && $translated_post->post_status === 'publish') {
            $url = get_permalink($translated_id);
            echo '' . "\n";
        }
        
        restore_current_blog();
    }
    
    // x-default per fallback
    switch_to_blog(2); // inglese come default
    echo '' . "\n";
    restore_current_blog();
}
add_action('wp_head', 'add_hreflang_tags', 1);

Metodo 3: Sitemap XML

L’approccio più scalabile per grandi network con migliaia di pagine. Richiede la generazione di sitemap personalizzate:

Crea una sitemap per ogni subsito con riferimenti hreflang
Usa <xhtml:link> per ogni URL alternativo
Carica le sitemap separate in Search Console
Monitora errori hreflang nel report Internazionalizzazione

Gestione delle relazioni tra contenuti

Il problema principale in un multisito è tracciare quali contenuti sono traduzioni di altri. Tre strategie operative:

Strategia 1: ID corrispondenti

Mantieni gli stessi ID post tra subsiti. Funziona se crei contenuti in modo sincronizzato, ma fragile con il tempo.

Strategia 2: Custom meta fields

Salva relazioni in post meta: _translation_group_id e _translation_lang. Più robusto e flessibile:

// Salva gruppo di traduzione
update_post_meta($post_id, '_translation_group', 'article-12345');
update_post_meta($post_id, '_translation_lang', 'it');

Strategia 3: Custom database table

Per network complessi, una tabella dedicata offre query più efficienti:

CREATE TABLE wp_translation_relations (
    id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
    translation_group VARCHAR(100) NOT NULL,
    site_id BIGINT UNSIGNED NOT NULL,
    post_id BIGINT UNSIGNED NOT NULL,
    lang_code VARCHAR(10) NOT NULL,
    INDEX idx_group (translation_group),
    INDEX idx_post (site_id, post_id)
);

Plugin vs implementazione custom

Nel 2026, i plugin SEO principali offrono supporto hreflang, ma con limiti in ambiente multisito:

Yoast SEO

Yoast offre hreflang via addon premium (€99/anno per network). Pro:

Interfaccia utente intuitiva
Validazione automatica degli errori
Integrazione con Yoast Duplicate Post

Contro: richiede configurazione manuale delle relazioni, performance impatto su network grandi.

RankMath Pro

Supporto hreflang incluso in Pro (€59/anno). Più leggero di Yoast ma meno testato su multisito complessi.

Implementazione custom

Per agenzie che gestiscono decine di siti client, una soluzione custom offre:

Controllo totale sulla logica di matching
Performance ottimizzate (no overhead plugin)
Integrazione con workflow di traduzione esistenti
Costi zero di licensing

Il codice presentato sopra è un punto di partenza solido che richiede 4-6 ore di sviluppo per personalizzazione e testing.

Testing e validazione hreflang

L’implementazione è solo metà del lavoro. La validazione continua è critica:

Strumenti di validazione

Google Search Console: Report Internazionalizzazione mostra errori hreflang (ritardo 48-72h)
Screaming Frog: Scansione con validazione hreflang in tempo reale (licenza €149/anno)
Hreflang Tags Testing Tool di Merkle: validatore online gratuito
Custom script: automatizza check via cron per monitoraggio proattivo

Errori comuni da evitare

Hreflang non reciproco: se IT linka EN, EN deve linkare IT
Self-referencing mancante: ogni pagina deve includere se stessa
Codici lingua errati: usa ISO 639-1 (it, en) non it-IT nel tag base
URL non canonici: hreflang deve puntare all’URL canonical
Missing x-default: sempre includere un fallback per utenti non targettizzati

Performance e caching

L’implementazione hreflang può impattare le performance, specialmente con switch_to_blog() che carica configurazioni di subsiti diversi.

Ottimizzazioni consigliate

Cache delle relazioni: salva mapping in transient WordPress (durata 24h)
Lazy loading: genera hreflang solo per post pubblicati, non draft
Query optimization: usa WP_Query ottimizzata o query SQL dirette
CDN awareness: assicurati che header HTTP siano preservati (Cloudflare, Fastly)

// Esempio cache con transient
function get_hreflang_data($post_id) {
    $cache_key = 'hreflang_' . $post_id;
    $data = get_transient($cache_key);
    
    if (false === $data) {
        $data = generate_hreflang_data($post_id);
        set_transient($cache_key, $data, DAY_IN_SECONDS);
    }
    
    return $data;
}

Monitoraggio e manutenzione

Un sistema hreflang richiede monitoraggio continuo. Configura alert per:

Errori 4xx/5xx su URL referenziati in hreflang
Cambiamenti di canonical che rompono le relazioni
Nuovi subsiti aggiunti al network
Contenuti archiviati o eliminati

Un approccio pragmatico prevede:

Audit trimestrale completo con Screaming Frog
Monitoring settimanale via Search Console API
Alert automatici su errori critici (via webhook o email)

FAQ

Devo usare hreflang anche se uso un plugin di traduzione come WPML?

WPML gestisce automaticamente hreflang, ma solo se configurato correttamente. In ambiente multisito, WPML non è nativamente supportato (richiede licenza Multilingual CMS che costa €195/anno). Se usi multisito nativo WordPress senza WPML, devi implementare hreflang manualmente o via plugin SEO compatibili. Verifica sempre l’output HTML effettivo: molti setup presentano hreflang duplicati o conflittuali.

Hreflang impatta la velocità di caricamento del sito?

L’impatto dipende dall’implementazione. Tag HTML nel head aggiungono 0.5-2KB per pagina (trascurabile). Header HTTP hanno zero impatto sul peso della pagina. Il vero collo di bottiglia è l’uso di switch_to_blog() in WordPress multisito, che può aggiungere 50-200ms per subsito interrogato. Soluzione: cache aggressiva delle relazioni con transient o object cache (Redis/Memcached). Con caching corretto, l’overhead è sotto 10ms.

Cosa succede se due subsiti hanno contenuti simili ma non identici?

Hreflang è pensato per contenuti equivalenti in lingue diverse, non per contenuti simili ma differenziati per mercato. Se IT e CH-it (Svizzera italiana) hanno contenuti diversi per lo stesso argomento, non usare hreflang tra loro: Google li considera pagine separate. Usa hreflang solo quando il contenuto è sostanzialmente lo stesso (traduzione o localizzazione minima). Per contenuti differenziati geograficamente, affidati a targeting geografico in Search Console e contenuti unici.

Come gestisco hreflang per pagine che esistono solo in alcune lingue?

Non tutti i contenuti devono esistere in tutte le lingue. Se un post esiste solo in IT e EN (ma non in DE), includi solo i tag hreflang per IT e EN, più x-default. Non inventare URL o rimandare a homepage: Google penalizza hreflang che puntano a contenuti non correlati. Se una lingua non ha l’equivalente, semplicemente omettila dai tag. Usa x-default per indirizzare utenti di lingue non supportate alla tua lingua principale (tipicamente inglese).

Posso usare hreflang per targeting geografico senza differenza di lingua?

Sì, hreflang supporta codici regionali: en-US, en-GB, en-AU per inglese USA, UK, Australia. In WordPress multisito, questo scenario è comune per e-commerce con prezzi/prodotti diversi per mercato. Implementazione identica, ma usa codici ISO 3166-1 Alpha 2 per la regione: hreflang="en-us". Attenzione: Google preferisce differenze sostanziali (pricing, disponibilità prodotti, info legali). Contenuti identici con solo cambio valuta potrebbero non giustificare subsiti separati.