I 4 errori tecnici SEO che frenano un sito ben scritto: cosa abbiamo trovato in 288 contenuti

Errori tecnici SEO che frenano un sito ben scritto

146 pagine su 242 senza schema FAQPage. Il dato arriva da un audit tecnico Orosfera anonimizzato di agosto 2026, condotto su 288 contenuti complessivi di un singolo sito WordPress redazionalmente curato: testi rivisti, nessun contenuto duplicato, autori reali. Nessun problema di scrittura, quindi. Eppure il sito era leggibile per gli umani e opaco per le macchine.

I 4 errori tecnici SEO che frenano un sito ben scritto

Gli errori tecnici SEO nel 2026 più costosi non sono quelli che si vedono leggendo una pagina: sono difetti di metadati, dati strutturati, gestione degli URL e tassonomia che emergono solo confrontando l’intero archivio. Nell’audit di agosto 2026 quattro anomalie ricorrenti spiegavano la maggior parte del divario tra qualità percepita e visibilità reale: assenza di markup FAQPage, mojibake nei metadati, due URL in competizione sullo stesso intento, contenuti recenti finiti in uncategorized. Tutte e quattro si diagnosticano in meno di mezza giornata, se sai cosa cercare.

Il punto scomodo è questo: chi ha investito in contenuti tende a cercare la causa del mancato posizionamento dentro i contenuti. Riscrive introduzioni, aggiunge paragrafi, allunga gli articoli. Nei progetti SEO che Orosfera segue nel mercato B2B italiano nel 2026, osserviamo che la qualità visibile del testo non esclude anomalie nei metadati e nella struttura — e che continuare a riscrivere un archivio tecnicamente rotto è il modo più elegante di bruciare budget.

146 pagine su 242 senza FAQPage: quando il contenuto è chiaro ma illeggibile per le macchine

Il numero va letto con precisione, perché il denominatore conta: su 242 pagine potenzialmente idonee al markup — pagine che contenevano già domande e risposte visibili nel testo — 146 non dichiaravano nessuno schema FAQPage. Non 146 su 288: i 288 sono i contenuti totali auditati, e non tutti hanno una struttura a domande. La differenza tra i due denominatori è esattamente il tipo di dettaglio che separa un audit da una schermata di tool.

Chiariamo subito una cosa, perché è il fraintendimento più diffuso: l’assenza di FAQPage non causa una perdita di ranking. Non esiste una penalizzazione per dati strutturati mancanti, e Google Search Central è esplicito sul fatto che il markup non è un fattore di posizionamento diretto. Quello che manca è un’altra cosa: la dichiarazione esplicita, in formato machine-readable, che quella pagina contiene una coppia domanda-risposta autonoma. In un ecosistema dove le risposte vengono assemblate da sistemi generativi, rinunciare a quella dichiarazione significa affidare l’estrazione a un parser che deve indovinare.

Come si verifica in pratica, senza tool a pagamento. Primo passo: apri la sitemap XML e scarica l’elenco completo degli URL. Secondo: esegui un crawl estraendo il contenuto dei blocchi <script type="application/ld+json"> per ogni URL. Terzo: filtra i risultati per "@type": "FAQPage" e incrocia con l’elenco delle pagine che contengono almeno due heading in forma interrogativa. La differenza tra i due insiemi è la tua lista di lavoro. Su Search Console, in parallelo, vai su Miglioramenti → Domande frequenti e confronta il conteggio degli elementi validi con il numero di pagine che dovrebbero averli: se la voce non compare affatto nel menu, il markup non esiste da nessuna parte.

Un esempio minimo di implementazione corretta, con le due sole proprietà obbligatorie:

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [{
    "@type": "Question",
    "name": "Quanto tempo serve per un audit tecnico?",
    "acceptedAnswer": {
      "@type": "Answer",
      "text": "Su un archivio di 300 contenuti, la fase diagnostica richiede tipicamente da tre a cinque giorni lavorativi."
    }
  }]
}

Gli anti-pattern che troviamo più spesso sono tre. Il markup che dichiara domande non presenti nel testo visibile — violazione diretta delle linee guida sui dati strutturati, e motivo di squalifica del rich result. Il template che inietta le stesse tre FAQ generiche su duecento pagine, trasformando il markup in rumore. E la FAQ chiusa in un accordion caricato via JavaScript dopo l’interazione utente, con il contenuto assente dall’HTML iniziale: tecnicamente il markup c’è, praticamente il contenuto non è verificabile. Su questo tipo di controllo incrociato tra HTML servito e HTML renderizzato conviene impostare un processo ricorrente, come facciamo nelle attività di SEO audit strutturato.

Il markup FAQPage non è un obiettivo in sé. È il livello minimo di leggibilità strutturata che rende una risposta citabile fuori dal tuo sito, e si inserisce in un lavoro più ampio di Answer Engine Optimization in cui la granularità della risposta conta più della lunghezza dell’articolo. Questo tipo di specifica può cambiare rapidamente — verifica sempre su Google Search Central e su schema.org per i tipi supportati e i valori aggiornati.

Un carattere sbagliato in un title: perché una sola pagina con mojibake fa scattare il controllo su tutte

Nell’audit di agosto 2026 abbiamo trovato una pagina con mojibake su title e meta description. Una. Su 288 contenuti. La reazione istintiva è archiviarla come svista: la correggi a mano in due minuti e passi avanti. È la reazione sbagliata, e la regola operativa che applichiamo è netta: un solo caso di mojibake estende il controllo a tutto l’archivio.

Il motivo è che il mojibake non è un errore di battitura. È il sintomo visibile di una discrepanza di codifica tra due sistemi che si sono parlati almeno una volta. Le apostrofi che diventano ’, le vocali accentate che diventano è o ù, le virgolette curve che diventano “: sono tutte firme di testo UTF-8 interpretato come Latin-1, o di doppia codifica applicata in fase di import. E un import non riguarda mai una singola riga.

Le origini che incontriamo più spesso sono quattro. Migrazione del database con dump esportato in latin1 e reimportato in utf8mb4. Popolamento massivo di title e meta description da CSV salvato con codifica di sistema Windows. Copia-incolla da documenti Word o Google Docs direttamente nel campo SEO del plugin, dove il valore viene salvato come postmeta senza normalizzazione. Sincronizzazione via REST API con un payload JSON servito senza header charset=utf-8. Nei primi tre casi il danno resta confinato ai contenuti toccati dall’operazione; nel quarto si ripresenta a ogni pubblicazione, silenziosamente.

La diagnosi è banale, se la fai in modo sistematico. Scarica l’elenco completo degli URL dalla sitemap, estrai title e meta description con un crawl, poi cerca nel dataset le sequenze tipiche con una regex del tipo (Ã.|â€.|Â.). Sul database, la stessa verifica si fa direttamente sui postmeta del plugin SEO:

SELECT post_id, meta_key, meta_value
FROM wp_postmeta
WHERE meta_value REGEXP 'Ã|â€| '
  AND meta_key IN ('_yoast_wpseo_title','_yoast_wpseo_metadesc',
                   'rank_math_title','rank_math_description');

Attenzione a cosa NON possiamo affermare: non abbiamo misurato un calo di CTR causato da quel carattere, e chiunque vi dica che un mojibake costa una percentuale precisa di clic sta inventando. Il problema è di chiarezza e di affidabilità percepita. Un title che mostra l’azienda comunica trascuratezza in SERP e produce una stringa sporca quando viene ripresa da un sistema generativo che cita il tuo brand. È un rischio, non una perdita quantificata.

Qui va una cicatrice operativa. In un intervento di bonifica su un archivio con caratteri corrotti abbiamo lanciato una sostituzione massiva via query SQL basata su una mappa di conversione — e nel primo giro abbiamo peggiorato la situazione su una parte dei contenuti, perché alcune stringhe erano codificate due volte e la sostituzione singola le ha lasciate in uno stato intermedio, questa volta non più riconoscibile dalla regex iniziale. Il workaround è stato ricostruire la mappa in due passaggi distinti, con backup del wp_postmeta prima di ogni esecuzione e verifica su un sottoinsieme di venti record. Regola imparata: sulle codifiche non si fa mai un solo passaggio cieco.

Nella sua attività di audit tecnico nel mercato italiano nel 2026, Orosfera riscontra che i difetti sistemici emergono confrontando pagine, template e URL, non leggendo un contenuto alla volta. Il mojibake è l’esempio più didattico: invisibile nel corpo dell’articolo, evidente nel dataset dei metadati. Se vuoi capire in che stato sono i metadati del tuo archivio, scrivici o chiamaci: ti rispondiamo direttamente noi.

Due URL sullo stesso intento: la cannibalizzazione che nasce dal restyling, non dalla strategia

Il terzo difetto trovato nell’audit di agosto 2026 è una cannibalizzazione tra URL vecchio e nuovo dello stesso argomento. Non due articoli scritti per sbaglio sullo stesso tema: un contenuto storico e la sua riscrittura, pubblicata su uno slug diverso, con il vecchio URL rimasto online, indicizzabile e privo di canonical verso il nuovo. Entrambi rispondevano alla stessa domanda. Entrambi competevano per le stesse query.

È il pattern più frequente tra gli errori tecnici SEO nel 2026 sui siti con almeno tre anni di storia editoriale, perché nasce da un’operazione ragionevole: aggiornare un contenuto datato. Il problema è la fase finale, quella che nessuno documenta nel workflow. Chi riscrive pensa al testo. Chi gestisce il CMS pensa alla pubblicazione. Nessuno dei due ha in carico la decisione su cosa fare del vecchio URL.

La soglia operativa che applichiamo è secca: 2 URL che rispondono allo stesso intento attivano un’analisi di cannibalizzazione, non una valutazione a occhio. L’analisi si fa in Search Console, in cinque passaggi concreti:

1. Rendimento → Risultati della ricerca → intervallo 12 mesi, così da avere una serie storica utilizzabile.
2. Aggiungi filtro Query, inserisci la query principale del contenuto in modalità “contiene”.
3. Passa alla scheda Pagine con il filtro query attivo: vedrai quali URL ricevono impression per quella famiglia di query.
4. Se compaiono due URL, apri il grafico di ciascuno e confronta l’andamento: la firma della cannibalizzazione è l’alternanza — quando uno sale, l’altro scende, e la posizione media resta mediocre per entrambi.
5. Esporta il CSV e ripeti su tutte le query dove entrambi gli URL appaiono, per capire quale dei due è il candidato naturale al consolidamento.

La decisione ha tre esiti possibili, non uno. Consolidamento: mantieni l’URL con il profilo di link e la storia migliore, trasferisci i contenuti utili dall’altro, redirect 301 dal perdente al vincitore. Differenziazione: i due contenuti rispondono a intenti realmente diversi (uno informativo, uno commerciale) e la soluzione è riscriverli per separarli, non fonderli. Deindicizzazione selettiva: il contenuto vecchio ha ancora valore per gli utenti che arrivano da link esterni ma non deve competere, quindi rel="canonical" verso il nuovo.

# Redirect 301 dopo consolidamento (.htaccess)
Redirect 301 /vecchio-slug-articolo/ /nuovo-slug-articolo/

Qui arriva il secondo attrito reale. In un consolidamento eseguito troppo presto abbiamo redirezionato il vecchio URL sul nuovo dopo appena due settimane dalla pubblicazione della riscrittura — e nelle sei settimane successive la visibilità complessiva sul cluster è risultata peggiore di prima. Il nuovo contenuto non aveva ancora accumulato segnali propri, e il 301 ha spostato autorità verso una pagina che il motore stava ancora valutando. Da allora la regola interna è aspettare che il nuovo URL mostri un trend di impression stabile per almeno quattro settimane in Search Console prima di chiudere il vecchio. Non è una legge fisica: è una precauzione che ci ha evitato di ripetere lo stesso errore.

Un dettaglio operativo che sfugge quasi sempre: la cannibalizzazione non riguarda solo articoli. Riguarda anche le pagine di archivio. Una categoria e un articolo pilastro sullo stesso tema competono esattamente come due post, e nei progetti dove lavoriamo sulla SEO indicizzazione il conflitto tag/categoria/pilastro è responsabile di una quota rilevante dei casi. Chi vuole una lettura più ampia del contesto competitivo italiano trova utile ragionare anche sulle specificità della SEO in Italia, dove la sovrapposizione semantica tra query brand e query generiche è particolarmente marcata.

Risolvere la cannibalizzazione su un archivio di 300 contenuti richiede una mappatura query-URL, non una checklist. Vuoi capire quanti conflitti reali hai? Mandaci un messaggio con la tua situazione: ti rispondiamo direttamente, senza form intermedi.

Due articoli recenti in “uncategorized”: la tassonomia come spia di un workflow rotto

Il quarto difetto è il più sottovalutato e il più informativo: 2 articoli recenti classificati in “uncategorized”. Due contenuti, pubblicati di recente, senza categoria assegnata. Un dettaglio da back-office, apparentemente.

Non è così. La categoria mancante non produce una penalizzazione — nessuna documentazione Google lo afferma e nessuno può dimostrarlo. Quello che produce è una catena di conseguenze concrete. Il contenuto non compare negli archivi tematici, quindi perde i link interni automatici che il template genera dalle pagine di categoria. Non entra nei moduli “articoli correlati” costruiti su tassonomia. Se il permalink include la categoria, l’URL nasce già con un segmento /uncategorized/ che nessuno vuole. E se il tema genera una pagina archivio per la categoria di default, quella pagina è indicizzabile e semanticamente vuota.

La regola che applichiamo è la più aggressiva delle tre: 1 solo contenuto recente in uncategorized attiva la verifica dell’intero workflow di pubblicazione. Non la correzione del singolo articolo — la verifica del processo. Perché un contenuto senza categoria significa che qualcuno, o qualcosa, ha pubblicato saltando un passaggio. E se è successo una volta con la tassonomia, sta probabilmente succedendo anche con altri campi non obbligatori: meta description, immagine in evidenza, canonical, data di aggiornamento.

Le tre cause che troviamo, in ordine di frequenza. Pubblicazione via REST API o via automazione, dove il payload non include l’array categories e WordPress assegna la default senza segnalare nulla. Pubblicazione manuale con l’editor a blocchi, dove il pannello Categorie è collassato e chi pubblica di fretta non lo apre. Migrazione di contenuti da un altro CMS, dove la mappatura delle tassonomie è stata fatta per la maggior parte dei post ma non per quelli con termini non corrispondenti.

Il controllo è immediato. In WordPress: Articoli → filtra per categoria → seleziona “Senza categoria” → applica. Oppure, se preferisci un dato interrogabile e ripetibile, via REST:

GET /wp-json/wp/v2/posts?categories=1&per_page=100&_fields=id,slug,date,title

La categoria con ID 1 è quella di default nelle installazioni standard. Se la query restituisce contenuti con date negli ultimi novanta giorni, il tuo workflow ha una falla attiva, non storica. La distinzione conta: un archivio con venti post senza categoria del 2019 è debito tecnico da bonificare; due post senza categoria di questo trimestre sono un processo che continua a produrre errori.

La correzione ha due livelli. Sul contenuto: assegna la categoria corretta, verifica che il permalink non sia cambiato (se lo è, serve un 301) e controlla che l’articolo entri effettivamente negli archivi e nei moduli correlati. Sul processo: rendi la categoria un campo bloccante. Nelle automazioni si fa validando il payload prima della chiamata POST; nella redazione umana si fa con una checklist di pubblicazione di sei righe che nessuno può saltare. Nei nostri progetti di content management questa è la prima cosa che documentiamo, prima di toccare qualunque contenuto.

Una nota sull’archivio “uncategorized” indicizzabile: se la pagina esiste e restituisce 200 con contenuto minimo, valuta se ha senso lasciarla accessibile ai crawler. Non è un’emergenza. È igiene.

Le tre soglie che usiamo per decidere se un difetto è isolato o sistemico

Il valore di un audit non sta nell’elenco degli errori. Sta nelle regole di escalation: quando un singolo caso obbliga a estendere il controllo. Senza soglie predefinite, ogni anomalia diventa una discussione, e le discussioni consumano più tempo delle correzioni. Queste sono le tre che applichiamo, con la logica dietro ciascuna.

Segnale rilevato	Soglia di escalation	Azione immediata	Effort
Mojibake in title o meta description	1 occorrenza	Regex su tutti i metadati + verifica charset del DB e del pipeline di import	Basso
Due URL che rispondono allo stesso intento	2 URL	Mappatura query-URL su 12 mesi in Search Console prima di qualsiasi redirect	Medio-alto
Contenuto recente in “uncategorized”	1 contenuto negli ultimi 90 giorni	Audit del workflow di pubblicazione, non solo correzione del post	Basso
Pagine con Q&A visibili senza markup FAQPage	Rapporto sul denominatore idoneo	Prioritizzazione per traffico e valore commerciale, non implementazione a tappeto	Medio

Le prime tre righe sono soglie assolute. La quarta no, ed è una scelta deliberata: implementare FAQPage su 146 pagine tutte insieme è un lavoro da settimane con un ritorno diluito. La sequenza sensata parte dalle pagine che già ricevono impression su query interrogative — le trovi in Search Console filtrando le query che contengono “come”, “quanto”, “perché”, “quale” — e scende verso il resto dell’archivio solo dopo aver verificato che il markup produca elementi validi nel report Miglioramenti.

Perché soglie così basse su mojibake e uncategorized? Perché entrambi sono indicatori di processo, non difetti isolati. Un carattere corrotto e una categoria mancante costano pochissimo da correggere e rivelano molto sulla catena che li ha prodotti. La cannibalizzazione, al contrario, ha una soglia bassa ma un’azione lenta, perché la correzione sbagliata è più dannosa dell’errore.

C’è un ultimo criterio che raramente viene messo per iscritto: la reversibilità. Aggiungere markup è reversibile. Correggere una codifica è reversibile con un backup. Assegnare una categoria è reversibile. Un redirect 301 su un URL con anni di storia è, in pratica, difficilmente reversibile — puoi rimuoverlo, ma i segnali non tornano allo stato precedente in tempi utili. Ordinare gli interventi per reversibilità decrescente è il modo più semplice di non fare danni mentre si impara il sito. Su archivi commerciali dove ogni URL ha un valore transazionale diretto, come nei progetti di eCommerce SEO, questo criterio diventa vincolante.

Un’osservazione sui numeri. Il denominatore 242 di questo audit non è trasferibile ad altri siti: dipende dalla struttura editoriale specifica di quell’archivio. Quello che è trasferibile è il metodo — costruire il denominatore delle pagine idonee prima di calcolare qualunque percentuale. La maggior parte dei report che vediamo confonde “pagine totali” con “pagine idonee” e produce numeri drammatici che non significano nulla. Questo tipo di lettura dei dati è esattamente ciò che distingue un’analisi del sito seria da un export di tool, e vale ancora di più quando i dati vanno collegati a decisioni di budget nell’analisi dei dati di marketing.

Cosa questi quattro controlli non vedono (e perché fermarsi qui è un errore)

Serve dirlo chiaramente, perché è il punto dove la maggior parte degli articoli sugli errori tecnici SEO nel 2026 si ferma vendendo una falsa completezza: quattro controlli non sono un audit tecnico. Sono quattro controlli.

Restano fuori dal perimetro almeno sette aree che possono spiegare, da sole, un mancato posizionamento. Il rendering: cosa vede effettivamente il crawler quando il contenuto principale arriva via JavaScript dopo l’idratazione. Le performance: le soglie ufficiali Core Web Vitals di Google restano LCP ≤ 2,5 s, INP ≤ 200 ms, CLS ≤ 0,1, e un sito che le sfora su mobile ha un problema che nessun markup compensa. I canonical: autoreferenziali, incrociati, contraddittori rispetto alla sitemap. Le catene di redirect: 301 concatenati che si accumulano a ogni restyling. Il robots.txt: direttive che bloccano risorse necessarie al rendering. Le sitemap: URL in stato 404, canonicalizzati altrove o in noindex. E i log del server, che sono l’unica fonte per sapere dove il crawl budget viene effettivamente speso.

Non li approfondiamo qui — sono capitoli autonomi, ognuno con la propria metodologia. Li nominiamo perché chiudere un audit dopo aver sistemato FAQPage, mojibake, cannibalizzazione e tassonomia significa aver ripulito la superficie di un archivio che potrebbe avere un problema strutturale a monte. È esattamente l’errore che vediamo commettere più spesso: correggere ciò che si misura facilmente e dichiarare risolto ciò che non si è mai misurato.

C’è anche un limite di applicabilità dei quattro controlli. Su un sito nuovo, con meno di cinquanta contenuti e un solo autore, tre dei quattro difetti sono statisticamente improbabili: non c’è storia editoriale da cui possa nascere cannibalizzazione, non ci sono migrazioni da cui possa nascere mojibake, e la tassonomia è ancora gestibile a mente. In quel contesto questa diagnostica produce poco valore, e il tempo è meglio investito su architettura informativa e copertura di intenti. I quattro controlli danno il massimo su archivi con almeno tre anni di storia, più di duecento contenuti e almeno una migrazione o un restyling alle spalle.

Un’ultima onestà: nessuno dei quattro difetti, corretto da solo, produce un salto di posizionamento garantito. La correlazione tra igiene tecnica e visibilità è reale, ma non è un rapporto uno a uno con un moltiplicatore prevedibile. Quello che la correzione garantisce è la rimozione dell’ambiguità: dopo, quando un contenuto non performa, sai che il problema è nel contenuto o nella competizione, non in un carattere sbagliato o in un URL gemello. È un guadagno diagnostico, prima che di traffico — e in un lavoro di consulenza SEO è la condizione per poter attribuire qualunque risultato a qualunque intervento.

Per una valutazione concreta di quali di queste aree pesano davvero sul tuo sito, contattaci — rispondiamo al telefono o su WhatsApp.

Il verdetto: cosa guardare lunedì mattina

Riassumo senza retorica.

Apri Search Console. Vai su Miglioramenti e guarda se la voce Domande frequenti esiste. Se non c’è, hai la risposta sul markup.

Poi scarica l’export delle query degli ultimi dodici mesi. Cerca le query dove compaiono due URL tuoi. Se ne trovi anche solo una coppia, hai un candidato al consolidamento.

Poi apri la lista articoli del CMS e filtra per categoria di default. Se c’è qualcosa pubblicato negli ultimi tre mesi, il problema non è quel post.

Poi scorri l’export dei title. Cerca Ã. Basta uno.

Quattro controlli, mezza giornata, nessuno strumento a pagamento obbligatorio. Non risolvono tutto. Ma dopo saprai se il tuo sito ha un problema di contenuti o un problema di infrastruttura — e quella distinzione, in un piano di lavoro annuale, vale più di dieci articoli nuovi. Gli errori tecnici SEO nel 2026 che costano di più sono quelli che nessuno cerca perché il sito, letto da un umano, sembra a posto.

Il resto è priorità. Sistemi prima quello che è reversibile e costa poco, misuri, e solo dopo tocchi gli URL. Chi fa il contrario passa i sei mesi successivi a capire cosa ha rotto.

Domande frequenti

Quanto costa far verificare questi quattro punti su un sito da 300 pagine?

La fase puramente diagnostica su un archivio di quella dimensione richiede tipicamente da tre a cinque giorni lavorativi, perché il tempo è concentrato nell’estrazione dei dati e nella costruzione dei denominatori corretti, non nel numero di pagine. Il costo dipende da quanto è accessibile l’ambiente: con accesso a Search Console, al CMS e al database la diagnosi è veloce; senza accesso al DB alcune verifiche vanno ricostruite dall’esterno e i tempi crescono. Per un preventivo sul tuo caso, scrivici o mandaci un messaggio: ti risponde un umano.

Posso implementare FAQPage se uso Yoast o Rank Math senza toccare il codice?

Sì. Yoast include un blocco FAQ nativo nell’editor a blocchi che genera automaticamente il markup, e Rank Math offre un blocco equivalente più il controllo granulare dello schema per singolo contenuto. Il limite di entrambi è lo stesso: gestiscono bene l’implementazione pagina per pagina, ma non ti dicono su quante pagine idonee il markup manca. Quel conteggio richiede un crawl con estrazione del JSON-LD, che nessuno dei due plugin fa nativamente.

Il mojibake nei title si corregge automaticamente aggiornando WordPress o il plugin SEO?

No. I caratteri corrotti sono già salvati come valori nel database, quindi nessun aggiornamento di software li riscrive: WordPress mostra esattamente ciò che trova nei postmeta. La correzione richiede una sostituzione a livello di dati, con backup preventivo e verifica su un campione ridotto prima dell’esecuzione massiva. Aggiornare l’ambiente serve invece a evitare che l’errore si ripresenti su nuovi contenuti, se la causa era nella pipeline di import.

Come distinguo una cannibalizzazione reale da due pagine che rispondono a intenti diversi?

Il test più affidabile è l’overlap di query in Search Console: se i due URL ricevono impression sulle stesse query e la posizione media di entrambi resta oltre la prima pagina, l’intento è lo stesso e stanno competendo. Se invece ciascuno domina un insieme di query distinto — uno su formulazioni informative, l’altro su formulazioni con intento commerciale — la separazione funziona e consolidare peggiorerebbe la copertura. Serve una serie storica di almeno tre mesi per leggere il pattern con affidabilità.

Ha senso mettere in noindex i tag e le categorie per evitare conflitti?

Dipende dal ruolo che quelle pagine hanno nell’architettura. Se un archivio di categoria è curato, ha una descrizione utile e riceve traffico proprio, escluderlo dall’indice significa perdere un asset. Se invece è una lista generata automaticamente su un tema già coperto da un contenuto pilastro, il conflitto è reale e la deindicizzazione ha senso. La regola pratica: prima misura le impression di quelle pagine in Search Console per dodici mesi, poi decidi.

Questi controlli valgono anche per un sito che non è su WordPress?

Tre dei quattro sì, senza modifiche: markup FAQPage, mojibake nei metadati e cannibalizzazione tra URL sono indipendenti dal CMS. Il quarto va tradotto: “uncategorized” è la manifestazione WordPress di un problema più generale, cioè la pubblicazione con campi tassonomici non popolati. Su Shopify, Drupal o un headless CMS il difetto equivalente è un contenuto senza collection, senza taxonomy term o senza tag di riferimento, e si trova interrogando l’API dei contenuti allo stesso modo.

Ogni quanto conviene ripetere questa diagnostica?

Su un archivio che pubblica con regolarità, un controllo trimestrale sui quattro punti è sostenibile e intercetta i difetti prima che diventino debito. La verifica va invece anticipata e ripetuta subito dopo tre eventi specifici: una migrazione di database, un cambio di tema o di plugin SEO, e l’attivazione di qualsiasi automazione che pubblichi contenuti via API. In quei tre casi il rischio di introdurre mojibake, categorie mancanti o URL duplicati è concentrato nelle prime settimane.

L’assenza di dati strutturati influisce sulla citabilità nelle risposte AI?

I dati strutturati rendono la relazione domanda-risposta esplicita e non interpretabile, quindi riducono l’ambiguità per qualunque sistema che estragga contenuto dalla pagina. Non esiste però una dichiarazione ufficiale che leghi il markup a una maggiore probabilità di citazione nelle risposte generative, e chiunque prometta una correlazione quantificata sta andando oltre le fonti verificabili. L’approccio ragionevole è trattarlo come igiene strutturale all’interno di una strategia di ottimizzazione per motori AI, non come leva di posizionamento.