Prima di iniziare a offrire la SEO tecnica come servizio, abbiamo fatto quello che la maggior parte delle agenzie evita: abbiamo puntato il processo su noi stessi.
Abbiamo condotto un audit tecnico completo su prixelo.com. Non un ambiente di staging, non un sito demo, ma il sito vero, quello che i potenziali clienti guardano prima di scriverci una email. Ci aspettavamo qualche piccolo problema. Abbiamo trovato sette cose che lavoravano attivamente contro di noi.
Questo articolo è quell'audit, senza filtri. Nessun cliente composito, nessun caso studio inventato. Solo quello che abbiamo trovato sul nostro sito e quello che ogni bug insegna su come i motori di ricerca vedono davvero una pagina rispetto a come un browser la mostra a te.
La sitemap non conteneva gran parte del sito
Abbiamo aperto sitemap.xml aspettandoci una formalità. Invece abbiamo trovato un file che elencava solo una frazione delle nostre pagine reali. Intere sezioni del sito — pagine pubblicate, collegate internamente e che ci aspettavamo posizionassero — semplicemente non c'erano.
Una sitemap non è un optional. È la mappa che consegni a Google così non deve indovinare la struttura del sito affidandosi solo alla scansione dei link. Una pagina online, collegata internamente e assente dalla sitemap può comunque finire indicizzata prima o poi, ma è più lento, meno affidabile, e segnala ai crawler che i metadati del tuo sito non sono attendibili. Se la sitemap sbaglia una volta, un crawler ha meno motivi per considerarla autorevole ovunque altrove.
Il nostro JSON-LD di Organization era rotto su tutto il sito
Controlliamo i dati strutturati con un validatore per abitudine. Il nostro ha fallito. Su ogni pagina.
La causa era un bug di escaping nel template: un carattere nel nostro schema Organization veniva codificato in modo errato al momento del rendering, il che rendeva il blocco JSON-LD sintatticamente non valido su ogni singola pagina in cui compariva. Google non fa un parsing parziale di un JSON rotto. O lo interpreta correttamente, oppure scarta l'intero blocco. Quindi, per tutto il tempo in cui questo bug è stato attivo, non avevamo dati strutturati che raggiungevano Google, su tutto il sito, mentre credevamo di avere un markup completo. È il tipo di bug che non produce alcun errore in un browser — la pagina sembra a posto — e nessun avviso a meno che tu non vada a cercarlo apposta in un validatore di schema o nel report sui risultati avanzati di Search Console.
Soft-404 che restituivano HTTP 200
Alcuni URL rotti o rimossi del sito non restituivano uno stato 404. Servivano contenuto di fallback — una pagina generica — mentre il server diceva al browser e a ogni crawler "200 OK, questa pagina esiste".
Questo è un soft-404, ed è peggio di uno vero. Un 404 autentico dice chiaramente ai motori di ricerca: questo URL non esiste più, toglilo dall'indice. Un soft-404 dice invece: questo URL va bene, continua pure a scansionarlo e indicizzarlo, anche se non c'è nulla qui. Se lasciato così com'è, questo spreca crawl budget su pagine che non esistono e può diluire il modo in cui vengono valutate le tue pagine reali, perché il crawler sta spendendo tempo e fiducia su vicoli ciechi che si dichiarano attivi.
Tag canonical che puntavano al dominio sbagliato
Diverse pagine avevano tag canonical che facevano riferimento alla versione non-www del nostro stesso dominio, che a sua volta reindirizzava altrove — un residuo di una configurazione precedente. Un tag canonical è un'istruzione diretta ai motori di ricerca: "indicizza questo URL come versione autorevole, non quello che stai guardando ora". Quando punta nel posto sbagliato, stai esplicitamente dicendo a Google di attribuire il merito a un altro URL per i tuoi stessi contenuti. Nel migliore dei casi viene ignorato. Nel peggiore, stai attivamente deviando i tuoi segnali di posizionamento lontano dalla pagina che ne ha bisogno.
Meta description troncate a metà parola
Un problema minore, ma del tipo che nel complesso erode la fiducia: diverse meta description venivano tagliate a metà parola direttamente nell'HTML grezzo, non solo troncate nella visualizzazione dei risultati di ricerca. È un bug di template o di limite di caratteri, non un artefatto di visualizzazione, e si manifesta come frasi incomplete dentro i tag <meta> — visibili a chiunque guardi il codice sorgente, e un segnale piccolo ma reale di scarsa cura su una pagina che sta cercando di apparire credibile.
Un robots.txt obsoleto proveniente da una directory precedente al sito attuale
Questa è stata la scoperta più strana. Il robots.txt servito non era quello presente nel nostro codebase attuale. Proveniva da una directory legacy rimasta sul server — un residuo di una versione precedente del sito che avrebbe dovuto essere dismessa del tutto. L'applicazione live non aveva alcuna idea che questo file esistesse, né che fosse quello che i crawler stavano effettivamente leggendo.
robots.txt è uno dei primi file che un crawler richiede. Se la versione servita è obsoleta, può bloccare percorsi che dovrebbero essere scansionabili, permetterne altri che non dovrebbero esserlo, o semplicemente puntare a una sitemap che non esiste più. E poiché vive fuori dal normale percorso di deploy, è invisibile a chiunque controlli il codebase attuale: devi verificare cosa viene effettivamente servito su quell'URL, non cosa pensi di aver pubblicato.
Pagine che dicevano ai crawler "non trovato" per via del rilevamento dello slug solo lato client
L'ultimo è un problema di rendering JavaScript, ed è una trappola comune per tutto ciò che è costruito con routing lato client. Alcune pagine determinavano quale contenuto mostrare in base a uno slug che veniva risolto solo nel browser, dopo l'esecuzione del JavaScript. I crawler che non eseguono completamente il JavaScript lato client — o che vanno in timeout prima che si risolva — ricevono la risposta iniziale del server, non trovano nessuno slug corrispondente, e si vedono servita una pagina di "non trovato". La pagina funziona perfettamente per una persona. È invisibile o non funzionante per un crawler che non riesce mai ad arrivare abbastanza avanti da vedere il contenuto reale.
Cosa insegna davvero tutto questo
Nessuno di questi bug è esotico. Sono le modalità di fallimento standard di qualsiasi sito che è cresciuto oltre la sua prima versione: infrastruttura legacy che nessuno ha dismesso, una modifica al template che ha silenziosamente rotto la codifica, uno schema di routing ottimizzato per gli utenti ma mai verificato rispetto al comportamento dei crawler. Ognuno di questi problemi era invisibile in un browser normale ed era invisibile a meno che qualcuno non andasse a cercare specificamente come un crawler vede la pagina, non come la vede una persona.
Questo è il vero lavoro. La SEO tecnica non è fatta di suggerimenti di parole chiave o calendari editoriali: è trovare il divario tra come appare il tuo sito a te e come appare ai sistemi che decidono se indicizzarlo e posizionarlo. Abbiamo risolto tutti e sette i problemi sul nostro sito nell'ambito dello sviluppo del nostro servizio di SEO, perché non avremmo mai venduto un audit che non avevamo prima eseguito su noi stessi.
Se vuoi sapere se il tuo sito ha versioni di questi stessi problemi, è esattamente quello che il nostro team SEO controlla per primo, prima di qualsiasi conversazione su contenuti o posizionamento.
