Competenza · SEO
SEO tecnico e strutturale — indicizzabilità, indirizzi canonici, sitemap generata dai dati, reindirizzamenti, titoli e descrizioni, contenuto sottile, velocità misurata in byte. Nessuna promessa di posizionamenti.
Già costruitoDue implementazioni proprie, entrambe aperte su disco. Prima: l’audit di questo sito — 249 indirizzi attraversati con richieste dirette, 23 colonne per indirizzo, il risultato in un file tabellare versionato accanto al codice, più le correzioni emerse da esso (indirizzo canonico risolto una volta per tutte per tutte le route, indirizzo di condivisione, sitemap generata dai dati). Seconda: `mega-seo-analyzer`, un analizzatore proprio con 16 moduli di analisi e un punteggio ponderato scritto esplicitamente nel codice. Ciò che non possiamo sostenere e non scriveremo: posizioni ottenute o percentuali di crescita. Non abbiamo misurazioni pubblicabili per questo.
La SEO classica è un lavoro di inventario, non di idee. Un motore di ricerca deve poter raggiungere ogni pagina, capire quale sia la sua versione ufficiale, ricevere un titolo e una descrizione non ripetuti e trovare abbastanza contenuto da meritare un posto in un elenco. Quasi tutto ciò che si rompe qui si può contare, e ciò che si può contare si può correggere.
Per questo iniziamo con una scansione completa, non con un campione. Su questo sito sono risultate 249 indirizzi, ciascuno con 23 colonne: codice di risposta, indirizzo canonico, titolo, descrizione, hreflang, numero di blocchi di dati strutturati, volume di testo visibile e il resto. Il risultato è un file tabellare versionato accanto al codice, quindi ogni affermazione qui sotto si può riprodurre con i comandi dell’allegato al rapporto.
Ciò che è emerso: 244 indirizzi rispondono 200 e cinque reindirizzano. 131 pagine non avevano un indirizzo canonico. 219 su 244 dichiaravano la pagina iniziale come indirizzo di condivisione, quindi ogni condivisione mostrava la pagina sbagliata. 100 titoli superavano i 60 caratteri, il più lungo avendone 106. 65 pagine condividevano una sola descrizione generata dal modello. 96 pagine avevano meno di 2.000 caratteri di testo visibile. Le prime due sono state corrette con una riga ciascuna nell’impostazione di base, che si applica a ogni route; il resto è nell’elenco di lavoro, con priorità scritta.
Questa pagina è una di tre. La SEO si occupa dei motori che restituiscono un elenco di link. La visibilità nelle risposte generate dai modelli è un’altra cosa e ha una propria pagina, perché si controlla in modo diverso e — importante — non si può promettere. Le risposte dirette e i dati strutturati sono la terza. Ciò che è comune a tutte e tre: la pagina deve essere accessibile, renderizzata sul server e avere un solo indirizzo ufficiale. Quella parte si fa una volta e vale per tutto.
Cosa comprende
Richieste dirette a ogni indirizzo conosciuto, senza seguire i reindirizzamenti, con al massimo sei richieste simultanee per non disturbare il server, e 23 colonne per indirizzo: codice, indirizzo canonico, titolo, descrizione, hreflang, numero di blocchi di dati strutturati, volume di testo visibile. Il risultato è un file tabellare che consegniamo. Su questo sito: 249 indirizzi, di cui 244 rispondono 200 e 5 reindirizzano.
131 pagine non dichiaravano alcun indirizzo canonico, e 219 su 244 dichiaravano la pagina iniziale come indirizzo di condivisione — quindi ogni condivisione sui social mostrava un’altra pagina. Entrambi sono stati corretti con una dichiarazione relativa nell’impostazione di base, che viene risolta per ogni route in parte. È una riga di codice al posto di una convenzione che ogni nuova pagina avrebbe dovuto ricordare da sola.
La mappa viene costruita dalle sorgenti di contenuto e passa attraverso una deduplicazione finale — su questo sito, 147 indirizzi, la stessa cifra nel codice e nel file servito in produzione. Uno script eseguito dopo la pubblicazione fallisce se la mappa perde una pagina o se compaiono varianti di indirizzo che non si aprono. Ciò che manca oggi, detto come mancanza: le voci non riportano la data dell’ultima modifica, e 93 indirizzi indicizzabili non sono ancora inclusi.
In una ristrutturazione, ogni indirizzo esistente riceve un verdetto: resta, viene reindirizzato permanentemente oppure scompare. Su questo sito sono risultati 43 reindirizzamenti nella configurazione. Verificati separatamente anche gli aspetti che nessuno testa: il passaggio dal dominio senza `www` a quello con `www` è unico; l’indirizzo con barra finale reindirizza correttamente; l’indirizzo scritto in maiuscolo restituisce 404, quindi non esiste un duplicato di scrittura.
100 titoli su 244 superano i 60 caratteri, il più lungo avendone 106 — il rischio è il troncamento nei risultati. 33 descrizioni superano i 160 caratteri, ma zero mancano. Più serio: 65 pagine condividono una sola descrizione generata dal modello, e 30 di esse differiscono tra loro per un totale di 240 byte. Mediana del testo visibile: 2.328 caratteri, con 96 pagine sotto i 2.000. Sono cifre, non impressioni, e ognuna ha dietro un elenco di indirizzi.
Il nostro analizzatore ha 16 moduli — on-page, performance, sitemap, sicurezza, accessibilità, infrastruttura dei nomi, informazioni di registrazione del dominio, link esterni, social network, stack tecnico, posizioni, ricerca di parole chiave, audit generale — più moduli di confronto: individuazione dei concorrenti, differenza di parole chiave, differenza di contenuto, riferimenti. Il punteggio generale è ponderato esplicitamente nel codice: performance 0,20, SEO 0,20, on-page 0,15, sicurezza 0,15, risposte dirette 0,10, accessibilità 0,10, social 0,10. I moduli che falliscono non abbassano il punteggio — escono dalla ponderazione, così che un servizio esterno in errore non produca un rapporto falso.
Un reindirizzamento fatto dall’interno dell’applicazione costruisce la pagina e solo dopo invia la risposta di reindirizzamento. Su questo sito ci sono 11 casi del genere, ciascuno dei quali produce oltre 200 KB di HTML prima di dire «vai altrove». Funziona, ma è uno spreco; spostarli nella configurazione è un piccolo intervento con effetto diretto sul budget di scansione. È nell’elenco delle correzioni, scritto come mancanza.
Ho richiesto cinque indirizzi con 18 identificatori di agente diversi e ho confrontato il codice, la dimensione e l’impronta del contenuto normalizzato. Tutti ricevono 200 ed esattamente lo stesso contenuto di un browser; `robots.txt` è identico, 129 byte, per tutti; non esiste blocco, challenge o limitazione per i crawler. L’unica differenza riproducibile — 237 byte in meno su una pagina dinamica, per tre agenti — proviene dal framework stesso, che invia HTML completo non streamato, quindi più contenuto già renderizzato, non meno.
Non promettiamo posizioni, percentuali di crescita o un numero di visite. Non abbiamo misurazioni pubblicabili per questo e non inventiamo. Ciò che consegniamo è verificabile in un altro modo: l’elenco degli indirizzi con il relativo stato, le correzioni eseguite, la verifica eseguita dopo la pubblicazione e la differenza misurabile tra lo stato prima e quello dopo — in byte, codici e numeri di pagina, non in promesse.
Come si presenta
La prima consegna è il file tabellare con ogni indirizzo e il suo stato su 23 colonne, più i comandi che lo riproducono. Da qui in poi, ogni discussione ha una riga dietro. È anche il momento in cui si scoprono gli indirizzi che nessuno sapeva esistessero.
Prima le cose che si risolvono in un punto e si applicano ovunque: l’indirizzo canonico, l’indirizzo di condivisione, il comportamento della pagina di errore, le regole per i robot. Poi quelle che richiedono lavoro sulla pagina: titoli, descrizioni, contenuto sottile. L’ordine non è negoziabile — al contrario, si riparano cento pagine a mano per qualcosa che si risolveva con una riga.
La sitemap si collega alle fonti di dati, così che una nuova pagina entri da sola. Gli indirizzi vecchi ricevono reindirizzamenti permanenti nella configurazione, non all’interno dell’applicazione. Consegniamo l’elenco completo delle decisioni, indirizzo per indirizzo.
Consegniamo uno script eseguito dopo ogni pubblicazione, che fallisce se un indirizzo canonico è sparito, se la sitemap ha perso una pagina o se `robots.txt` ha iniziato a bloccare risorse di rendering. Senza di esso, le correzioni si erodono in pochi mesi e nessuno se ne accorge fino al successivo audit.
Se hai la console di ricerca e uno strumento di analisi, impostiamo la reportistica sopra di essi e definiamo cosa seguire. Se non li hai, il primo passo è averli — e lo diciamo prima, non dopo. Ciò che non facciamo: non riportiamo posizioni da uno strumento terzo come se fossero dati di origine.
I dati
Le domande che pone chiunque abbia un responsabile della protezione dei dati — poste qui prima che le ponga lui.
Un caso
La situazione
Un sito ristrutturato di recente, con circa 250 indirizzi pubblici. Tutti rispondevano 200 e niente sembrava fuori posto. La domanda di partenza non era «come aumentiamo il traffico», ma «cosa dichiara ogni pagina su se stessa».
Cosa abbiamo costruito
Ho esaminato ogni indirizzo con richieste dirette, senza seguire i reindirizzamenti, con al massimo sei richieste simultanee, e per ciascuno ho scritto 23 colonne in un file tabellare versionato accanto al codice. Su di esso ho eseguito verifiche separate: chi dichiara quale indirizzo canonico, chi dichiara quale indirizzo di condivisione, quali lunghezze hanno i titoli e le descrizioni, quante pagine condividono la stessa descrizione del modello, quanto testo visibile ha ciascuna, cosa risponde il server a 18 identificatori di agent diversi, cosa offre per compressione e protocollo. Ogni cifra è stata letta dalla risposta reale, non dedotta dalla configurazione.
Cosa è emerso
244 indirizzi rispondono 200, cinque reindirizzano. 131 pagine non dichiaravano un indirizzo canonico; 219 su 244 dichiaravano la home page come indirizzo di condivisione. Entrambi sono stati corretti con una dichiarazione relativa nell’assetto di base — due righe che si applicano a ogni percorso, invece di una correzione per ogni pagina. Il resto delle constatazioni è entrato in un piano in undici passi, in ordine di impatto: 100 titoli oltre 60 caratteri, 65 pagine con descrizione del modello, 96 pagine con meno di 2.000 caratteri di testo, 93 indirizzi indicizzabili mancanti dalla mappa, 11 reindirizzamenti effettuati dall’interno dell’applicazione.
Cosa non dice il caso
L’audit è stato eseguito senza accesso alla console di ricerca e senza dati di traffico, deliberatamente, e il limite è scritto nel rapporto: possiamo dire cosa non va tecnicamente, non cosa accade nei risultati. Dei undici passi del piano, due sono applicati oggi; il resto sono lavori aperti, non spuntati. Un rapporto che dichiara tutti i passi conclusi nel giorno in cui è stato scritto non è un rapporto.
Domande
Il pubblico è diverso. SEO si rivolge ai motori che restituiscono un elenco di link — la sua pagina appare, l’utente clicca. GEO si rivolge ai modelli generativi che compongono una risposta e possono citare una fonte; lì non esiste posizione e non esiste garanzia, quindi si lavora su ciò che può essere controllato, non sul risultato. AEO si rivolge alle risposte dirette — il frammento estratto, il pannello informativo, la risposta vocale — e si basa su dati strutturati corretti. La base è comune: pagina accessibile, renderizzata sul server, con un unico indirizzo ufficiale. Quella parte si fa una volta.
Un file tabellare con ogni indirizzo del sito e il suo stato su 23 colonne — codice di risposta, indirizzo canonico, titolo, descrizione, hreflang, blocchi di dati strutturati, volume di testo — più un rapporto scritto con le constatazioni in ordine di impatto, ciascuna con il punto nel codice, il criterio e la correzione. E i comandi che riproducono ogni cifra. Su questo sito sono risultate 249 righe; è proprio nel repository, accanto al codice.
No, e neppure una posizione specifica. Non abbiamo misurazioni pubblicabili per risultati di questo tipo e non inventiamo. Quello che possiamo mostrare è la differenza verificabile: quante pagine non avevano un indirizzo canonico prima e quante ne hanno adesso, quante dichiaravano in modo errato l’indirizzo di condivisione, quanti vecchi indirizzi sono rimasti senza reindirizzamento. Su questo sito i numeri sono stati 131, rispettivamente 219 su 244. Questi sono fatti; una posizione promessa non lo è.
Da uno script eseguito dopo ogni pubblicazione, che verifica gli indirizzi canonici, le ancore di contenuto, la mappa del sito e `robots.txt`, e si interrompe se qualcosa è scomparso. Le correzioni SEO si erodono esattamente come qualsiasi altra convenzione non scritta: qualcuno aggiunge una nuova pagina, dimentica una dichiarazione e nessuno se ne accorge fino al successivo audit. Uno script se ne accorge subito.
Entrambi hanno la loro utilità, ma l’analisi tecnica la facciamo con un analizzatore proprietario: 16 moduli — on-page, performance, sitemap, sicurezza, accessibilità, infrastruttura di nomi, registrazione del dominio, link esterni, reti sociali, stack tecnico, posizioni, parole chiave — più moduli di confronto con i concorrenti. Il punteggio generale ha pesi scritti nel codice, non nascosti: performance e SEO 0,20 ciascuno, on-page e sicurezza 0,15 ciascuno, gli altri 0,10 ciascuno. Un modulo che fallisce esce dalla ponderazione invece di produrre un punteggio falso.
Le segnaliamo come rischio, non come opportunità. Su questo sito, 100 dei 147 indirizzi nella sitemap sono combinazioni servizio × dominio, e 65 pagine condividono una sola descrizione da template — 30 di esse differiscono tra loro di 240 byte in totale. Un motore di ricerca tratta questo come contenuto prodotto su scala, e il rischio è una sanzione, non un aumento di visibilità. La soluzione è contenuto reale su ogni pagina o meno pagine. Non consigliamo la generazione di pagine come strategia.
Conta, ma non nella forma in cui di solito viene venduta. Non vi diamo un punteggio di laboratorio, perché è facile da spostare e non dice cosa vive un visitatore. Vi diamo byte misurati: quanto pesa l’HTML compresso, cosa viene trasmesso a ogni navigazione, cosa contengono i pacchetti JavaScript, se il server offre compressione moderna e un nuovo protocollo. Su questo sito: non offre né Brotli né HTTP/2, il catalogo delle traduzioni costa circa 70 KB compressi a ogni navigazione, e un pacchetto di 443 KB contiene quattro cataloghi di lingua di cui solo uno è usato. Tutti e tre sono nell’elenco delle riparazioni.
È una decisione del proprietario del sito, non nostra, e richiede la separazione di tre categorie che oggi sono trattate allo stesso modo sulla maggior parte dei siti: crawler di ricerca che riportano persone indietro, agenti attivati da un umano che ha richiesto la pagina, e crawler di training. Le regole per loro sono indipendenti. Su questo sito al momento esiste una sola regola generale, quindi la posizione è implicita — e lo diciamo, invece di fingere che sia una strategia. I dettagli riguardano la pagina di visibilità nelle risposte generate.
Non compriamo link e non costruiamo reti di siti. Non generiamo pagine su scala per coprire combinazioni di parole. Non riportiamo posizioni prese da uno strumento terzo come se fossero dati di origine. E non dichiariamo un audit concluso senza il file tabellare e i comandi che lo riproducono — un rapporto che non si può verificare da soli non è un audit, è un’opinione.
14 di esse sono codice e file dei nostri repository. Non ne pubblichiamo il nome né la riga: insieme, in un'unica pagina, descriverebbero con troppa precisione come sono costruiti sistemi che non sono solo nostri. Le esaminiamo con te, nel repository, su richiesta — la verifica resta possibile, solo che avviene in una discussione.
Raccontaci il tuo processo. Insieme stabiliamo cosa vale la pena costruire, cosa possiamo collegare e come verifichiamo il risultato.