"Free website check", la prima trappola
Il problema con gli analizzatori di pagina singola
Il problema con i punteggi SEO
Il problema con check list SEO e strumenti che le usano
23 problemi da discutere
Il problema con gli strumenti in generale
Lo strumento SEO più importante in assoluto
Un malinteso di lunga data
Conclusioni
"Free website check", la prima trappola
Di solito funziona così: sai molto poco di Ottimizzazione per i Motori di Ricerca, ma sai di volere ottimizzare il tuo sito web.
Così cerchi su Google parole tipo [free seo checker], [check seo score free], [free seo check online], o altre varianti, e finisci su una pagina che ti chiede l'URL del tuo sito.
Inserisci l'indirizzo della Home Page, e dopo pochi secondi ottieni una lista piena zeppa di quanto si presuppone sia buone o cattivo. Talvolta c'è anche un "punteggio SEO" che fa figo, qualsiasi cosa voglia dire.
La lista di quanto si suppone sia errato è talvolta impressionante, potresti esserne intimorito, e il più delle volte sei invitato a lasciare il tuo contatto per ottenere un preventivo gratuito da parte di un consulente umano.
Altre volte sei semplicemente capitato in un popolare articolo intitolato "I 10/20/.../50 errori SEO più comuni" o qualcosa di simile.
Talvolta non sono proprio errori, altre volte dipende dalla situazione. Bisogna conoscere il contesto per giudicare.
Lo scopo di questo articolo è aiutare le persone con bassissima conoscenza di SEO a sopravvivere questo primo passo, e possibilmente risparmiare soldi, tempo e brutte esperienze. Un altro obiettivo è fornire a principianti SEO la conoscenza per superare i falsi dogmi precedentemente acquisiti e crescere ulteriormente nella professione.
Il problema con gli analizzatori di pagina singola
Compreresti mai una casa dopo averne visto solo la facciata?
Potrebbe dire molto, ma se vuoi comprare una casa dovresti visitarla, indagare sulle spese annuali, le spese straordinarie preventivate, sapere quali lavori andranno fatti, sapere delle fondamenta, il terreno, il vicinato, l'esposizione al sole, la distanza dal centro, i trasporti disponibili, e tante altre cose.
Quegli analizzatori di singola pagina guardano solo la home page, la facciata.
Non solo, analizzano aspetti che a volte potrebbero avere ben poco a che fare con il vero valore di un sito web in termini di SEO (specie se presi da soli), di prestazioni, design, comunicazione, usabilità, esperienza utente... ma parlerò di questi dettagli più tardi.
Il problema con i punteggi SEO
Avere un "punteggio SEO" fa figo, giusto? Immagina poter esibire un "97/100 di punteggio SEO" sui social media!
Il problema è che i punteggio SEO non significano nulla.
Nessun numero mono-dimensionale può descrivere come un sito web si comporti in termini di ottimizzazione per i motori di ricerca.
Prima di tutto, è come cercare di descrivere le qualità di una persona con un valore numerico. Supponi sia una scala da 0 a 10. Supponi si dica sia un 7.
Che caspita vuole dire? È un uomo, o è una donna? Bionda o bruna (e quale sarebbe meglio?). È una persona di buon cuore? Una scienziata, un'atleta? E se è un'atleta, è una centometrista, o una maratoneta, o una sollevatrice di pesi?
OK, supponiamo di valutare più qualità con punteggi distinti, per poi farne la media. La media finale non dice nulla sui valori da cui è stata calcolata (a meno che non sia zero o 100). Presa da sola non significa nulla.
E non esiste solo la SEO. Potremmo costruire un sito web con un perfetto "punteggio SEO" (qualsiasi cosa significhi), ma non usabile, con pessima esperienza utente, dolorosamente lento, che non converte affatto. Ricevuto il messaggio?
Il problema con check list SEO e strumenti che le usano
Strumenti SEO di bassa qualità sono ovunque, ma ciò che normalmente li rende di bassa qualità non sono le capacità di programmazione del programmatore, è la di lui/lei scarsa conoscenza della SEO tecnica.
Il programmatore legge una guida base SEO, di solito direttamente dagli anni '90 e già allora zeppa di concetti errati, e prova su di essa a sviluppare un tool.
Altri programmatori provano poi a svilupparne un clone basato sugli stessi concetti errati, e ora ci sono diversi strumenti a dire le stesse cose sbagliate.
Gli anni passano, gli strumenti sono sempre meno aggiornati, ma sono strumenti economici e così tutti li usano, e gli utenti si rinforzano a vicenda le proprie convinzioni perchè gli strumenti dicono così.
23 problemi da discutere
Quanto segue è una lista parziale di "problemi SEO" comunemente elencati, che pensiamo dovrebbero essere discussi.
Alcuni sono errori veri, ma hanno un impatto poco significativo, altri non sono nemmeno errori; in tutti i casi crediamo che i SEO debbano essere in grado di comprendere tutti i perché e i come riguardo a essi.
Errore SEO? File sitemap.xml non trovato
Vi sono due grosse lacune in questo test.
Prima di tutto, non è scritto da nessuna parte che una Sitemap XML si debba chiamare sitemap.xml; può avere qualsiasi nome, qualsiasi estensione, in alcuni casi potrebbe anche trovarsi in un posto diverso.
Usare /sitemap.xml è solo una convenzione comune, nulla di scolpito nella pietra e infatti spesso non è così.
Pertanto non avere un file /sitemap.xml non significa nulla.
Magari vogliamo riformulare la questione come "Non avere una Sitemap XML", va bene?
Sarebbe un errore SEO?
La dura verità è che il 99.9% di tutti i siti web non ha alcun vantaggio SEO ad avere una Sitemap XML.
Se il tuo sito web è composto di solo poche decine/centinaia di pagine, e non cambiano spesso (prendi per esempio un blog, con solo nuovi contenuti aggiunti), il più delle volte una Sitemap XML a elencarne tutte le pagine non reca alcun vantaggio.
Lo scopo principale delle Sitemap XML è la "discoverability", e i motori di ricerca di solito possono già scoprire tutti i contenuti del sito semplicemente seguendone i link interni. È il meccanismo primario di scoperta dei contenuti per i motori di ricerca.
La sitemap in questi casi non porta alcun vantaggio.
Una sitemap può essere di aiuto quando i contenuti non sono raggiungibili seguendo dei link interni, ma in tale caso è meglio aggiustare i problemi di navigazione del sito.
Le Sitemap XML hanno anche scopi secondari, ognuno di essi raramente importante:
- Suggerire al motore di ricerca l'URL canonical delle pagine (ossia l'URL preferito da mostrare in SERP).
Usare link interni consistenti e il tag canonical è un modo migliore per gestire la questione. - Specificare la frequenza di crawl (esplorazione) preferita per le tue pagine (tag changefreq)
La verità è che non hai la sfera di cristallo e non puoi sapere quanto sovente cambierai il contenuto delle tue pagine, e il valore è largamente ignorato dai motori di ricerca. - Specificare una priorità di esplorazione per le tue pagine (tag priority)
Potrebbe avere senso, ma una buona struttura di link dovrebbe già assicurarlo, e hai bisogno comunque di una buona struttura di link. - Specificare la data di ultima modifica delle tue pagine (tag lastmod)
Probabilmente è l'unico della lista varrebbe la pena di considerare, però un header HTTP è di solito un modo migliore per comunicarla invece del tag XML lastmod. Sì, un motore di ricerca potrebbe leggere il valore di lastmod prima di decidere se effettivamente ri-esplorare la risorsa. Il problema è che troppe sitemap sono generate con valori farlocchi di lastmod, un motore di ricerca ci mette poco a capire che la risorsa non è cambiata affatto e perdere fiducia nella sitemap XML del sito. Se lo usi, assicurati sia accurato.
Ma allora, quando sono utili le Sitemap XML?
Grossi siti web con migliaia, centinaia di migliaia o milioni di URL - molti dei quali con contenuti che cambiano frequentemente - quelli sono i siti web che possono ottenere il meglio dal protocollo Sitemap XML.
E-commerce, annunci, offerte immobiliari, ...tutta questa classe di siti web con pagine che scadono e altre che necessitano aggiornamenti, dove non puoi semplicemente mettere in home page un link a una pagina cambiata per elevarne la priorità di re-indicizzazione, perché ce ne sono troppe. Questa è la classe di siti web di cui stiamo parlando.
Supponi di avere un grosso sito e-commerce con migliaia e migliaia di pagine di prodotto. Decidi di cambiare il prezzo a una linea di prodotto, e hai bisogno che qualche decina di prodotti siano re-indicizzati il prima possibile così che il motore di ricerca ne abbia una vista aggiornata. Costruisci una sitemap dedicata/temporanea con solo quelle pagine di prodotto, e la invii al motore di ricerca.
Questo è solo uno dei tanti possibili esempi.
Non solo stai dicendo al motore di ricerca l'elenco esatto delle sole pagine vuoi siano reindicizzate, puoi avere una migliore comprensione del loro stato di indicizzazione tramite la pagina dedicata alle Sitemap della Google Search Console.
Come produttori di uno strumento SEO, abbiamo aggiunto un generatore di Sitemap XML in Visual SEO Studio con tutti questi concetti in mente: così a differenza di altri generatori di sitemap abbiamo reso possibile generare sitemap che contengano solo una selezione delle pagine web.
Indovina un po'? La funzione - con nostra stessa sorpresa - è stata una delle più apprezzate, in larga misura da gestori di siti e-commerce.
Una Sitemap XML generata "al volo" dalla piattaforma di e-commerce dovrebbe essere preferibile (perché sarebbe sempre aggiornata), tuttavia la maggior parte delle piattaforme manca dell'abilità di generare sitemap dedicate con solo una selezione di pagine, o fa un lavoro mediocre quando lo permette. Pertanto i gestori di siti trovano più conveniente acquistare una licenza di Visual SEO Studio Edizione Professional per un costo contenuto e risparmiare un sacco di soldi curando al meglio il loro sito e-commerce.
Nota: un altro caso in cui una sitemap temporanea può essere di aiuto è una migrazione di sito, con una Sitemap XML che elenchi tutti i vecchi URL che portano un redirect HTTP 301 così che il motore di ricerca li scopra più velocemente senza considerare le nuove URL scoperte tramite esplorazione di link come dei contenuti duplicati.
Errore SEO? sitemap.xml non indicata in robots.txt
Questo punto potrebbe avere del valore (se lo riformuliamo come "Sitemap XML non indicata in robots.txt", visto che non possiamo conoscere il nome della sitemap). Noi stessi suggeriamo di elencare le sitemap (e non una singola sitemap che contiene la lista di tutte le pagine del sito) in direttive Sitemap: del robots.txt.
Dato che non esiste un unico motore di ricerca, elencarle lì ti esime dall'avere un "webmaster account" per ogni motore di ricerca e inviare le Sitemap XML a ognuno di essi.
Però il vantaggio è molto limitato, spesso trascurabile.
Supponiamo che l'unico traffico organico lo ricevi da Google (nella maggior parte delle nazioni ha una quota di mercato del 97% o superiore), dovresti comunque avere elencato le tue Sitemap XML nella Google Search Console senza aver bisogno di elencarle anche nel robots.txt
Se aggiungiamo che, come abbiamo discusso nel punto precedente, nella gran parte dei casi avere una Sitemap XML è un vantaggio trascurabile, puoi capire come considerarlo un errore sia una parola troppo grossa.
Se il tuo sito è uno dei pochi a necessitare veramente di delle Sitemap XML, è probabile che il loro elenco cambi di frequente e se ti importa solo di Google potresti ritenere più semplice amministrarlo solo tramite la Google Search Console invece che aggiornarlo ogni volta nel file robots.txt
Errore SEO? robots.txt non trovato
Un file robots.txt mancante è perfettamente lecito secondo il Robots Exclusion Protocol, significa solo che agli user-agent non sono poste restrizioni nell'esplorare il sito web.
Se ciò fosse quanto desideri, come lo si dovrebbe mai considerare un errore?
Il più delle volte i proprietari di siti non restringono granché con il file robots.txt; la maggior parte di siti basati su WP usa una versione del robots.txt fatta con lo stampino che potrebbe anche essere tranquillamente omessa.
Di nuovo, i siti web che veramente necessitano un file robots.txt sono siti complessi, perlopiù casi simili a quelli che beneficiano dall'uso delle Sitemap XML.
Per tali siti, essere in grado di inibire l'esplorazione a bot di motori di ricerca abbastanza educati è un modo pratico ed economico per ridurre il consumo di crawl budget.
Di solito preferiamo utilizzare un file robots.txt, ma per la grande maggioranza dei siti web non averlo non è un vero problema.
Nota: quando Visual SEO Studio non trova un file robots.txt lo segnala come un "avvertimento", che non significa un "errore leggero", ma un qualcosa da controllare se accidentale o voluto: i file robots.txt tendono a "scomparire" accidentalmente, specialmente in alcuni ambienti di lavoro corporativi con grossi team di sviluppo web...
Errore SEO? Usare un robots.txt
Se alcune check-list riportano il non avere un file robots.txt come un errore, ve ne sono altre che riportano come un errore averlo!
Qui la giustificazione è ancora più debole: dicono che se usi la direttiva Disallow: (che è lo scopo principale dei file robots.txt) potresti tradire il nome della cartella di aree riservate del sito.
Le aree riservate dovrebbero sempre essere protette da password, quella è la prima e più importante protezione. Ci sono casi in cui aggiungere le loro cartelle in direttive Disallow ha senso, quando un link diretto all'area riservata è presente in una pagina pubblica, ma in tale caso la si potrebbe scoprire comunque.
Errore SEO? Lettere maiuscole nell'URL
Vi sono molti strumenti e guide a dire che gli URL delle pagine dovrebbero essere composti da sole lettere minuscole.
È solo una convenzione molto diffusa, ma non rispettarla non è un errore. Il protocollo HTTP e le specifica per gli URL consentono caratteri ASCII nell'URL, siano essi maiuscoli o minuscoli.
Per cui non è un errore.
Perché tanti tool lo riportano come un problema, e perché esiste questa convenzione?
I primi webmaster scrivevano il codice HTML delle pagine manualmente, i CMS (Content Management Systems) non esistevano o erano alla loro infanzia. I link erano codificati manualmente e un modo per sbagliare di meno la forma maiuscola/minuscola dell'URL era di tenerlo sempre tutto minuscolo. Usare un'altra convenzione sarebbe stato altrettanto valido: tutto maiuscolo (ma rende gli URL brutti a vedersi), o qualsiasi altra combinazione.
Ancora oggi vi sono molte occasioni in cui gli URL sono inseriti manualmente anche in siti WP per cui la convenzione potrebbe avere sempre senso per molti. Quello che non ha alcun senso è che vi siano persone convinte che alcuni caratteri maiuscoli nell'URL li possano penalizzare!
La vera regola per i caratteri degli URL nei link dovrebbe essere: devono essere corretti, rispettando esattamente l'URL che intendono puntare.
Errore SEO? Caratteri "underscore" nell'URL (invece dei trattini)
Questo può in effetti essere considerato un errore SEO minore, almeno per Google:
storicamente Google non considerava i caratteri underscore ("_") come separatori di parole. Il motivo è che agli albori molti utenti dei motori di ricerca erano programmatori che spesso cercavano nomi di costanti di programmazione, che spesso erano composti da underscore. Non considerarli come separatori di parole era una ottimizzazione per uno scenario d'uso comune.
Per quanto ne sappiamo, ciò è valido ancor oggi.
Allora perché includerlo in questa lista?
Perché riteniamo l'importanza dell'errore sia troppo spesso esagerata.
- Molti siti web (wikipedia.org è l'esempio più notevole) vivono piuttosto bene nonostante abbiano gli underscore nei propri URL.
- Correggere il problema non implica solo riscrivere gli URL, dovresti anche impostare una redirezione HTTP 301 dai vecchi ai nuovi URL; attendere che il motore di ricerca indicizzi i nuovi URL, e apprenda in qualche modo che gli URL nuovi che ha scoperto sono in realtà i vecchi andando a sbattere contro i 301 (una sitemap temporanea qui potrebbe essere di aiuto, come già spiegato nella sezione sulle Sitemap).
Spesso i webmaster reputano il costo non valga i benefici, e adottano la regola generale di non usare gli underscore nei nuovi URL, e lasciare i vecchi così come sono.
Un aspirante SEO dovrebbe conoscer perché la regola esiste, che il suo impatto è spesso trascurabile, e tutto quanto si dovrebbe fare se lo si volesse correggere.
Errore SEO? Caratteri "percent-encoded" nell'URL
Anche espresso come "caratteri Unicode nell'URL", o "Accenti negli URL", è largamente - e erroneamente - ritenuto un errore.
Spieghiamo un po' meglio la questione:
Dato che le specifiche per gli URL accettano solo caratteri ASCII, i primi indirizzi URL utilizzavano solo caratteri dell'alfabeto occidentale. Una convenzione comune - ancora ampiamente in uso - per linguaggi con lettere accentate era usare le lettere equivalenti prive di accento, per esempio "e" invece di "è".
Per lingue che usano alfabeti non occidentali i webmaster erano di solito forzati a usare la lingua Inglese per gli URL; per alcune lingue come il Russo erano usate convenzioni di traslitterazione all'alfabeto occidentale. Nessuna delle soluzione era soddisfacente per gli utenti, e impediva ai motori di ricerca per molte lingue di ottenere un contesto dagli URL.
In seguito furono introdotte alcune innovazioni: per avere gli accenti o altri caratteri Unicode nei percorsi questi dovevano essere codificati con il "percent-encoding" prima di viaggiare sul filo. Per i nomi di dominio (IDN, Internationalized Domain Names), i caratteri Unicode devono essere trasformati con un'altra codifica chiamata "punycode".
I browser odierni effettuano la trasformazione in modo in gran parte trasparente, così che l'utente veda un indirizzo - per esempio - in cirillico senza scorgere tutti quei segni % seguiti da coppie di caratteri a rendere gli URL illeggibili.
Anche tutti i maggiori motori di ricerca sono in grado di comprendere i caratteri Unicode negli URL.
Sfortunatamente, troppi aspiranti SEO pensano siamo ancora a inizio anni '90.
Per ricapitolare: non c'è nulla di sbagliato nell'usare caratteri Unicode negli URL, e se aiuta gli utenti specie per lingue non occidentali allora dovresti usarli.
Noi di aStonish di solito raccomandiamo solo di non usare spazi (la cui codifica percent-encode è la sequenza %20) negli URL, perché gli indirizzi web sono spesso copiati nelle e-mail, e i programmi di e-mail provano a renderli dei link, ma uno spazio nell'URL farebbe credere loro che l'URL termina prima.
Errore SEO? Basso rapporto testo/HTML
Diversi programmi indicano come errore quando il rapporto testo/HTML è al di sotto di una certa soglia.
Non esiste un rapporto magico sopra il quale si venga penalizzati. L'informazione deve essere presa con un granello di sale.
Ci sono pagine web posizionate bene e pagine posizionate male, con tutti i possibili rapporti.
Ai motori di ricerca importa ben poco di quanto HTML c'è nelle tue pagine web a confronto con il testo. Infatti, prima di valutare una pagina fanno del loro meglio per eliminare gli elementi accessori (menu, piè di pagina...), individuare il contenuto principale, ed estrarne il testo puro.
Permettetemi di spiegare perché il parametro esiste:
È un modo facile per i produttori di strumenti SEO per permetterti di individuare pagine con "thin content".
Il ragionamento è che se una pagina ha poco o nessun contenuto, il suo rapporto testo/HTML sarà basso.
È un po' come i canarini usati nelle trincee della Grande Guerra per rilevare i gas letali. Se il canarino muore, potrebbe essere a causa di un attacco con il gas. Oppure potrebbe essere per qualche altro motivo.
Una ulteriore indicazione data dalla misura del rapporto è suggerire quando il template del sito web ha una struttura HTML complessa, rendendo la pagina mediamente più pesante e più lenta a caricarsi.
Errore SEO? Basso conteggio parole
Scommetto che hai letto in molti posti varie teorie sul numero perfetto di parole che una pagina dovrebbe avere per meglio posizionarsi in SERP.
300 parole, almento 300 parole, 500 parole, 1500 parole, 1850 parole, 3000 parole... molti annunci di ricerca copywriter citano uno di questi numeri come prerequisito.
Ancora, non esiste un numero esatto di parole per posizionare una pagina. Dipende in larga misura dalla parola chiave (o frase chiave). Se la keyword è una parola completamente inventata che nessun altro usa, potresti scrivere un articolo con solo quella parola e posizionarti primo (e unico) nella SERP. Quando è un termine di ricerca più difficile le cose cambiano, ma non esiste un numero magico. Si dovrebbe scrivere il numero "giusto" di parole qualsiasi esso sia, cioè non prestare tanto attenzione al numero esatto di parole, e usare quante parole ti servono per esprimere i concetti.
Ci sono diversi motivi per cui uno strumento SEO potrebbe esibire un report di "conteggio parole":
- per aiutare gli editori a rispettare politiche interne basate sul conteggio di parole (che siano basate su solidi motivi o no non ha importanza, gli editori spesso lo richiedono)
- come nel caso del rapporto testo/HTML per individuare pagine con contenuti sottili. È più facile contare il numero di parole nell'intera pagina e poi elencare le pagine con il numero più basso piuttosto che provare prima a eliminare il boiler-plate (Nota: La funzione "Leggibilità" di Visual SEO Studio "Readability" ha una metrica di conteggio parole, ma prima rimuove tutti i contenuti boiler-plate (menu, footer, sezioni laterali...) ed è pertanto più adatta a individuare pagine con contenuti sottili).
- individuare pagine "hackerizzate" con contenuti nascosti
Errore SEO? Tag title o meta descrizioni multipli
Sì, una pagine con più tag title o meta descrizioni è in effetti un errore SEO, ma qual è l'impatto?
Se i due tag title sono identici, non vi sono conseguenze: il motore di ricerca prende il primo che trova. Lo stesso dicasi per la meta descrizione.
Altra questione è quando il primo è vuoto, i se i due hanno contenuti differenti.
Per cui: è un errore SEO e andrebbe messo a posto. In alcune casi non causa danni.
Errore SEO? Più titoli H1
Voglio essere chiaro: avere più titoli H1 nella stessa pagina non è un errore.
Non è mai stato un errore di validazione, anche prima di HTML5. HTML5 lo incoraggia persino.
La regola "Un solo H1 per pagina" è solo una comoda convenzione SEO. Dato che i tag H1..H6 sono gerarchici, ha senso usare un solo H1 come titolo del documento nella parte visibile del contenuto della pagina (il tag title ha uno scopo simile, ma non è visibile nel contenuto visuale della pagina).
Che succede se si usano più tag H1, da un punto di vista SEO?
Nulla di drammatico: il peso associato al tag H1 è suddiviso equamente tra i tag H1 utilizzati, il peso dei tag H2..H6 è scalato di conseguenza.
Ci sono casi in cui l'errore è involontario: per esempio alcuni template mal fatti racchiudono elementi boiler-plate (logo, text in side elements...) con degli H1 o altre intestazioni H*. Ciò andrebbe corretto e l'utente deve avere un modo per rilevarlo.
In aStonish suggeriamo di usare un solo H1 per pagina per motivi pratici, senza pretendere sia un errore SEO non farlo.
Il nostro tool Visual SEO Studio nel report "Suggerimenti HTML" elenca le pagine con più titoli H1; non lo presenta come un errore, ma come un Avvertimento (ossia qualcosa l'utente magari vorrebbe sapere e andare a controllare) perché essendo la regola comune così largamente diffusa e accettata potrebbe essere che le occorrenze multiple siano involontarie.
Errore SEO? title e H1 sono uguali
Alcuni strumenti e check-list segnalano come un errore SEO avere title e tag H1 identici.
Il ragionamento è: se si usa lo stesso testo, si perde l'occasione di posizionarsi per altri termini o sinonimi. Un po' di senso lo ha.
Bisogna ricordare che il tag title di pagina di solito contiene il nome del marchio o del sito nella parte finale, per cui una comparazione esatta non funzionerebbe.
Ma se sono identici è davvero un problema?
Qui in aStonish in passato abbiamo sviluppato due distinti sistemi CMS proprietari (sì, ci sono occasioni in cui ha senso farlo, più che altro per integrarsi con codice proprietario). Decidemmo di automatizzare la generazione del title concatenando il titolo H1 (obbligatorio nei nostri sistemi) con il brand del sito. È una soluzione comune a molti sistemi CMS.
Non solo: forzammo la generazione delle meta descrizioni con lo stesso contenuto mostrato in modo prominente come sotto titolo della pagina.
Adottiamo ancora la stessa soluzione con il sito visual-seo.com.
Perché decidemmo di fare così?
Title e meta descrizione hanno un difetto: non sono normalmente visibili al personale editore del sito (o almeno non prominenti ai loro occhi, dipende dallo strumento da loro usato).
Col tempo si fa manutenzione alle pagine, i titoli cambiano, i testi cambiano, anche la semantica del contenuto potrebbe cambiare. E quei title e meta descrizioni potrebbero essere divenuti vetusti e non riflettere più la missione della pagina. Legarli a una porzione di testo visualizzato lo impedisce.
Le persone incaricate di editare i contenuti hanno raramente una mentalità orientata alla SEO, per loro title e meta descrizione sono qualcosa che il CMS chiede loro di popolare, ma non ne vedono il motivo perché la pagina appare uguale senza. Allora li lasciano vuoti. Magari hai spiegato ad alcuni di loro cosa sono, ma l'hanno subito dimenticato, magari non ne hanno mai appreso l'importanza, e il messaggio non è stato passato ai nuovi membri del team.
Crediamo che comporre la prima parte del title con il contenuto del tag H1 sia una soluzione che più che compensa il minore vantaggio di avere due testi leggermente diversi, perché garantisce che il title sia sempre popolato e allineato alla missione della pagina.
Errore SEO? Immagini senza attributo ALT
Non avere un attributo ALT popolato con un testo descrittivo è normalmente un errore SEO.
Tuttavia, pochi sanno che, secondo le specifiche HTML, l'attributo ALT dovrebbe essere lasciato vuoto per immagini non rilevanti.
Le immagini "non rilevanti" sono immagini aggiunte come elementi decorativi senza che forniscano informazioni aggiuntive.
Solo l'autore può di solito decidere se un'immagine è decorativa o informativa. Un report che elenchi tutte le immagini prive dell'attributo ALT è un prezioso alleato.
Nota: tieni a mente che lo scopo principale dell'attributo ALT è assistere utente con handicap visivi a fruire dei tuoi contenuti con un dispositivo text-to-speech.
La SEO dovrebbe essere sempre vista come un obiettivo secondario.
Errore SEO? Catene di re-direzioni
È vero: re-direzionamenti multipli aumentano il numero di chiamate HTTP effettuate per raggiungere l'URL di destinazione, incrementando così il tempo totale e peggiorando l'esperienza utente.
Idealmente, le catene di redirect dovrebbero essere rimosse e dovresti usare un singolo redirect per giungere alla destinazione finale.
I redirezionamenti hanno l'ulteriore svantaggio SEO di procrastinare l'esplorazione da parte di googlebot perché il crawler del motore di ricerca non segue direttamente i redirect, spedisce l'informazione a Google che pianificherà una esplorazione dell'indirizzo appena scoperto (se è un nuovo URL che non ha mai visto prima).
Ma è proprio così brutto?
Googlebot può seguire fino a cinque redirezionamenti in catena. I browser hanno una tolleranza anche maggiore.
Inoltre, i redirect permanenti sono "cachable", significa che una volta che a un browser è presentato un redirect HTTP 301 ne ricorderà l'URL di destinazione e la prossima volta che l'utente cliccherà sullo stesso link il browser salterà la chiamata intermedia.
I browser ricordano le redirezioni (permanenti), e lo stesso vale per i motori di ricerca.
Uno scenario tipico è quando vuoi migrare un sito, poni da HTTP a HTTPS. E decidi pure di cambiare dalla versione www. all'URL "nudo".
Potresti impostare una regola unica per gestire tutte le combinazioni in un colpo solo (cosa che raccomandiamo), ma trovi più facile copiare regole che trovi su Internet e incollarle nel tuo file .htaccess
Ti stai sparando in un piede? Alla peggio la migrazione prenderà un po' più di tempo, ma se ci puoi convivere non è una tragedia. Dopo un po' la migrazione sarà completata comunque.
Ci sono anche altri singoli URL redirezionati per normale manutenzione di pagine. Anche se imposti una regola per ottenere il passaggio HTTP->HTTPS e www.->naked URL in un colpo solo, la redirezione dedicata alla pagina sarà concatenata quando l'utente clicca su un vecchio link esterno trovato su un altro sito. Non puoi sempre prevenire l'esistenza di catene di redirect dato che non sarebbe pratico in molti casi.
E comunque le catene di redirect funzionano lo stesso.
Per riassumere: minimizza le catene di redirect, e non preoccuparti troppo se non puoi evitare un numero limitato di concatenazioni.
Errore SEO? Mancata validazione W3C
Pagine HTML non validate non sono un errore SEO per-se.
Ai Motori di Ricerca - per dirla tutta - non importa. Google non ti penalizzerà mai il sito per non avere l'HTML pienamente validato.
Allora, perché la condizione è citata in così tante check-list?
Potrebbe essere per ignoranza, potrebbe essere perché gli autori della check-list l'hanno ripetuta dopo averla letta in altre liste.
Esiste qualche reale motivo per giustificarla?
Parzialmente: i motori di ricerca devono "parsare" l'HTML per estrarne testo titolo, meta tag, etc...
Un documento HTML veramente mal formato potrebbe impedire al parser HTML di effettuare questo compito basilare.
Se hai un documento HTML perfettamente validato sei sicuro nulla romperà il parser di Google, ma è un po' come costruire un muro alto 300 metri per difendere i tuoi confini quando uno molto più piccolo sarebbe sufficiente.
Verosimilmente la vasta maggioranza di pagine web non passerebbe un testo di validazione W3C completo. Eppure i motori di ricerca possono analizzarle senza problemi.
Devi avere una codifica HTML davvero orribile in alcuni punti critici per impedire a Google e altri motori di ricerca di comprendere i tuoi contenuti.
Per cui, avere pagine web pienamente validate W3C è perlopiù uno spreco di tempo, e spesso ben difficile da ottenere (dipende dal CMS, dal tema, dai plugin usati...)
Assicurati che il tuo HTML non sia troppo errato - e la maggior parte dei CMS ottengono questo compito minimale - e raramente dovrai preoccuparti.
Nota: Il prodotto di aStonish, Visual SEO Studio, è fornito di un validatore di HTML integrato.
Non effettua una piena validazione di conformità W3C, e crediamo sia una scelta molto migliore:
- segnala solo gli errori di validazione HTML più gravi che potrebbero danneggiare la tua SEO (es. tag title male formati)
- è incredibilmente veloce!
Errore SEO? Lunghezza del title inferiore a XXX caratteri
Troverai un po' ovunque in Internet raccomandazioni di tenere i tag title più corti di 71 caratteri, 70 caratteri, 65 caratteri, 55 caratteri, e così via.
Lasciate ch'io sia chiaro:
La lunghezza in caratteri del tag title nella SERP di Google è stato uno dei più grandi, ampiamente diffusi miti nell'industria SEO da anni, inconsapevolmente perpetrato da diversi venditori di software e influencer SEO, che si influenzano vicendevolmente rafforzando le proprie convinzioni. Concedo la buona fede, sia chiaro.
La vera misura da guardare è l'ampiezza in pixel del title.
Non sono più intelligente degli altri, solo ho un background da programmatore, ambiente dove è ben compreso che se si vuole fare sapere se un testo scritto con un font non mono-spaced può stare dentro un rettangolo, occorre misurarne le dimensioni con API di basso livello offerte dalla GDI del sistema operativo. I browser alla fin fine sono delle applicazioni GUI come le altre, e obbediscono alle stesse regole.
Le lettere "m" e "i" non occupano lo stesso spazio (quando usano un font non mono-spaced, come quello usato nella SERP di Google). Puoi fare stare molte più "i" che "m" nello stesso spazio orizzontale.
Anche Google nel suo vecchio report (ora ritirato) "Miglioramenti HTML" nella Google Search Console nel segnalare i titoli troppo lunghi (ossia tag title che apparivano troncati nella SERP con dei puntini di sospensione alla fine) non ha mai parlato di una soglia basata sul numero di caratteri.
Per forza, non esisteva alcuna soglia basata sui caratteri, la sola cosa importante era se l'ampiezza del testo del title mostrato a video con il font utilizzato eccedesse o no la larghezza in pixel dell'elemento DIV che lo conteneva.
Ha sempre funzionato così, almeno per Google. Alcuni cosiddetti influencer hanno fatto finta che Google avesse cambiato sistema; i cosiddetti influencer sono sempre pronti a spargere miti, molto meno ad ammettere la propria ignoranza.
Ora, non tutti nell'industria SEO erano all'oscuro del fatto che l'ampiezza in pixel fosse quella da considerare, eppure molti specialisti SEO hanno continuato ad adottare politiche basate sulla lunghezza in caratteri per mancanza di strumenti migliori; produttori di strumenti SEO hanno continuato a fornire misure basate sul numero di caratteri per ignoranza, o mancanza di conoscenza tecnica su come computare la larghezza in pixel.
Molte raccomandazioni come "meno di 55 caratteri" sono basate su dati statistici, dove il numero limite era scelto per avere una ragionevole sicurezza che il testo non apparisse troncato quando mostrato in SERP.
È un po' draconiano, perché indica come errori molti title ben scritti che in realtà non verrebbero troncati.
C'è altro da aggiungere:
Di solito i tag title sono composti - è una convenzione molto diffusa che anche noi raccomandiamo - dal vero titolo della pagina seguito da un separatore seguito dal nome brand del sito.
Ora, ti importa davvero se la parte con il nome del brand è troncata quando gli utenti della SERP possono leggere la parte significativa del titolo senza problemi?
È inoltre stato dimostrato che anche se parti del title sono troncate in SERP, il loro contenuto è considerato come parte del tag title (che riceve un peso maggiore quando valutato) fino a 12 parole. Quindi anche se troncati alcuni titoli potrebbero essere un buon mezzo per dare prominenza a keyword secondarie. Ciò che importa di più è che la parte più importante del title sia leggibile.
Nota:
Visual SEO Studio - il tool prodotto da aStonish - è stato il primo strumento SEO in assoluto a prediligere la dimensione in pixel per titoli e meta descrizioni. In seguito introducemmo anche metriche basate sulla lunghezza in caratteri dietro insistenza di agenzie clienti ancora ancorate alla vecchia scuola, ma non le raccomandiamo e non ne diamo evidenza.
È probabilmente anche l'unico strumento SEO a fornire un report basato sul numero di parole che compongono il title, in accordanza alla regola delle 12 parole.
Errore SEO? Lunghezza della meta descrizione inferiore a YYY caratteri
Come già spiegato per il tag title, la misura importante è la dimensione in pixel del testo contenuto nella meta descrizione.
Nel caso della meta descrizione stimare se il test sarà troncato è più soggetto ad errore perché i motori di ricerca spesso dedicano un po' dello spazio disponibile a immagini, stelline, o altri elementi che potrebbero apparire in seguito all'uso di dati strutturati. Il termine di ricerca utilizzato potrebbe anche essere evidenziato in grassetto occupando leggermente più spazio (ma quando ciò accade, non è infrequente che Google abbia scelto un altro frammento di testo da mostrare in SERP al posto della meta descrizione).
Il più delle volte, una metrica basata sul numero di caratteri ha davvero poco senso e dovresti prediligere una metrica basata sulla dimensione in pixel che fornisce risultati più precisi.
Anche qui Visual SEO Studio è stato il primo tool SEO a fornire - dalla sue primissime versioni beta pubbliche - metriche basate sulla dimensione in pixel, anni prima degli altri produttori.
Errore SEO? Uso di trattini nel nome del dominio
Non esiste una penalizzazione SEO per l'utilizzo di trattini nel nome di dominio.
E chi lo usa ben sa di usarlo, non ha molto senso ricordarglielo.
Perché uno dovrebbe scegliere un nome di dominio con un trattino?
Prendete il caso di visual-seo.com per esempio. La versione senza trattino non era disponibile. Non usata, ma custodita da domain squatters desiderosi di fare soldi offrendola a un prezzo oltraggioso. No grazie.
Volevamo un dominio vicino al marchio registrato per il prodotto, e abbiamo deciso per la versione con trattino perché non penalizza.
Vi sono altri validissimi motivi per cui si potrebbe preferire un nome di dominio con trattini.
Pensate alla quantità di nomi di dominio non intenzionalmente inappropriati che esistono (es. whorepresents.com, expertsexchange.com, speedofart.com e tanti altri).
Talvolta un altro paio di occhi e un piccolo trattino possono fare risparmiare tanta ridicolizzazione e imbarazzo!
Un'idea di strumento migliore sarebbe l'analizzare nomi di dominio senza trattino per vedere se potrebbero esservi significati ambigui.
Errore SEO? Non usare Dublin Core
Alcuni analizzatori puoi trovare in giro sul web segnalano il seguente messaggio d'errore: "Questa pagina non sfrutta i vantaggi di Dublin Core."
La cosa mi fa ridere ancor più di un nome di dominio imbarazzante non intenzionale:
Dublin Core non ha nulla ha che fare con la SEO, non è usato da nessuno dei principali motori di ricerca e per quanto ne so non lo è mai stato.
(Controlla la pagina "Meta tag riconosciuti da Google", Dublin Core non lo troverai).
La cosa peggiore è che ci sono cosiddetti influencer che ancora nel 2019 diffondono tattiche SEO errate invitando ad aggiungere il markup di Dublin Core al codice delle tue pagine!
Ma cos'è Dublin Core innanzi tutto?
Dublin Core era una proposta di demarcazione per decorare l'HTML con metadati e descrivere entità per il web semantico. Per quanto ne so non è stato mai usato dai motori di ricerca, e per i suoi obiettivi è stato superato da schema.org e microdati.
Perché possiamo trovare risorse che lo indicano come una tecnica SEO?
È quanto m'ero proposto di scoprire.
Ho scoperto su un marketplace uno script PHP scritto da uno sviluppatore Lituano.
Analizza una singola pagina web seguendo una check-list di raccomandazioni SEO contestabili (immagino che l'autore non sia un SEO, ha probabilmente letto solo qualche check-list su Internet) e si integra con le API di Google Page Speed.
Fa ben poche cose e male, ispezionando solo una pagina. Ma presenta i risultati in modo carino e spaventa gli utenti per il numero di presunti errori trovati.
Lo script ha conosciuto una certa popolarità perché ha un costo molto basso, è multilingua e facile da personalizzare e integrare in un sito web.
Vi sono molte (aspiranti?) agenzie web e SEO che lo integrano offrendolo come strumento gratuito per gli utenti a modo di esca per poi offrire loro una consulenza a pagamento.
Per riassumere:
- Dublin Core non è usato dai motori di ricerca.
- Aggiungere il suo markup alle tue pagine è un assoluto spreco di tempo.
- Se hai energie per aggiungere dei meta dati, un uso molto, molto migliore di tempo e risorse potrebbe essere aggiungere dati strutturati di schema.org riconosciuti da Google!
Errore SEO? [Avere / non avere] il meta tag keywords
Purtroppo ci sono tool che riportano l'una o l'altra.
Chiunque desideri fare SEO dovrebbe avere chiara in testa una cosa: il meta tag keywords è completamente ignorato dai motori di ricerca.
Google non l'ha mai usato, altri potrebbero averlo fatto in passato. Bing una volta dichiarò che potrebbero ispezionarlo alla ricerca di segnali di keyword stuffing, ma di non usarlo per il posizionamento.
Per cui usarlo NON aiuta la SEO.
E usarlo NON danneggia la SEO.
C'è qualche giustificabile motivo per una o l'altra delle due contrastanti indicazioni?
In aStonish generalmente invitiamo i nostri clienti a non popolare il meta tag keywords sia perché è inutile, sia perché - se hai fatto la tua ricerca di parole chiavi per bene - vorrebbe dire dare gratis ai tuoi concorrenti il tuo duro lavoro. Non è scienza infusa ispezionare un testo per estrarne i termini di ricerca più usati, ma elencarli in chiaro in un campo facilmente accessibile è assurdo!
Quando potrebbe avere senso farlo?
Tenendo a mente che quel campo è ignorato dai motori di ricerca, un editore umano potrebbe volere nel proprio CMS un campo dove salvare le parole chiavi di riferimento, e magari essere in grado con strumenti interni di provare a stimare quanto il testo risponda alle keyword di riferimento. In tali casi, potrebbero trovare comodo usare il campo meta keywords fornito dal CMS semplicemente perché è lì, magari senza nemmeno sapere finirà nell'HTML della pagina, o disinteressandosene.
Quando anni fa noi di aStonish sviluppammo un CMS proprietario per un grosso cliente (avevano bisogno di integrare molto codice legacy e usare un CMS commerciale non era fattibile) aggiungemmo all'editor visuale un campo Keywords esattamente per quello scopo.
L'unica differenza pratica era che non generava un campo meta keywords nell'HTML, volutamente!
Fornimmo anche strumenti per analizzare il testo e vedere come rispondesse agli intenti di ricerca elencati nel campo Keywords (rozzi, ma no, erano molto meglio dell'assurda metrica chiamata "keyword density"!), ma sto divagando...
Errore SEO? "Keyword density" sopra il xx.x%
È molto triste nel 2019 dover ancora ricordare ad aspiranti SEO che la cosiddetta "keyword density" (KD) non ha alcun significato.
Non è usata come parametro dai motori di ricerca, e mai, mai, mai lo è stata.
Per essere chiari: i motori di ricerca non funzionano così. Anche i libri di testo classici sulla Information Retrieval non citano la KD perché in nessun modo modella alcunché di utile. La KD non tiene conto di troppe cose: stemming, sinonimi, frequenza d'uso nelle statistiche della lingua, ed è sé stessa un modello matematico a dire poco mediocre.
Pensavamo che ormai fosse una conoscenza ben radicata dopo tanti anni spesi a cercare di acculturare professionisti SEO. Eppure ci sono in giro strumenti SEO - alcuni anche popolari - che aggiungono report sulla "keyword density" per i loro utenti, rafforzandone pertanto la convinzione che la KD sia qualcosa di serio.
C'è un qualsiasi motivo perché uno strumento voglia fornire una metrica KD, oggi?
Sto provando a fare l'avvocato del diavolo ora. Alcuni potrebbero considerare la KD uno strumento per rilevare contenuto spam, ed è molto facile da computare.
Peccato che tutte le sue limitazioni come potenziale fattore di ranking siano lì anche per un potenziale rilevatore di spam: per esempio per la lingua Italiana scopriresti che la parola "il" ha una KD molto alta (alcuni provano a girarvi attorno ignorando le "stop words", ma la KD rimane uno strumento molto mediocre ad ogni modo).
Ci sono altre metriche ch'io possa guardare?
La Information Retrieval fornisce altre formule basate su fondamenta teoriche e matematiche molto più solide. Una relativamente popolare è TF-IDF, anch'essa è lontana dall'ideale non tenendo di nuovo conto di cose come permutazioni, sinonimi, e statistiche di linguaggio. Come tutte le sue varianti più note, è una formula inventata negli anni '70, vecchia di quasi mezzo secolo.
Esistono altre formule un po' migliori, ma non sono soluzioni adatte per uno strumento SEO: sono spesso poco comprensibili per l'utente medio, o richiedono pesanti computazioni che renderebbero lo strumento inutilizzabile.
Motori di ricerca come Google sono molto avanti nella Information Retrieval di quanto sia insegnato nelle Università. Il funzionamento interno è perlopiù un segreto aziendale, ma sappiamo utilizzano immensi grafi di entità per ricercare, cosa che uno strumento SEO relativamente economico non può permettersi di offrire.
Noi di aStonish abbiamo sempre categoricamente rifiutato di aggiungere il calcolo della KD all'interno di Visual SEO Studio, e continueremo a farlo.
Non escludiamo per il futuro di equipaggiare Visual SEO Studio (o un altro prodotto futuro) con un mezzo più affidabile per analizzare quanto un testo risponda a un dato termine di ricerca.
Errore SEO? Keyword non presente nella meta descrizione
La meta description non è usata per il posizionamento (almeno non da Google).
Per cui aggiungere la tua keyword nella meta descrizione non dà alcuna spinta al posizionamento.
Un beneficio potrebbe essere che Google tende a enfatizzare in grassetto il termine di ricerca usato quando lo trova nel testo in SERP, per cui aggiungerla nel tag meta descrizione potrebbe aiutare ad aumentare la CTR (click through rate, ossia la probabilità che un utente clicchi sul tuo risultato in SERP).
Google è anche in grado di riconoscere entità e simonini, e talvolta li mette in evidenza in SERP; che essi siano evidenziati in grassetto o no potrebbe essere più utile aggiungervi i sinonimi per confermare all'utente che la risorsa è effettivamente quanto stava cercando.
Raccomandiamo pertanto di ignorare questa regola e creare meta descrizioni che massimizzino la CTR.
Errore SEO? Non avere gli script/pixel di FB/Twitter/...
Il più delle volte gli script dei social media hanno l'effetto di rallentare le pagine web, così che al contrario potrebbero essere dannoso alla SEO delle tue pagine.
A parte le prestazioni, la loro presenza non influenza la SEO di una pagina.
La nostra raccomandazione:
Usali quando ne hai bisogno, e fai del tuo meglio per minimizzarne l'impatto che hanno sulla velocità della pagina.
Il problema con gli strumenti in generale
Ci sono cose che i tool tradizionali proprio non possono fare. Prendi i tool SEO per esempio. Potresti dare loro in pasto l'indirizzo di un sito web, e questi potrebbero verificare che non ci sono link rotti, né titoli duplicati, etc... Poi dai un'occhiata al sito e questo sembra un residuo degli anni '90, con font comics sans e testo lampeggiante e GIF animate. E menu a tendina gerarchici inutilizzabili. E il testo è scritto da cani, o magari anche offensivo per il lettore.
Suggerimento: prima di esaminare un sito web con uno strumento, prima fai sempre un'ispezione manuale. Sempre!
Lo strumento SEO più importante in assoluto
Il tool SEO più importante è il cervello umano. Punto.
Potresti ribattere che aggiungendo la giusta dose di Intelligenza Artificiale uno strumento potrebbe in effetti essere in grado di valutare anche quanto sopra citato.
Bhé, potrebbe essere. Ma fammi indovinare: non stavi cercando uno strumento gratuito o economico? E magari vuoi aggiornamenti regolari e assistenza tecnica, giusto? Scommetto non vuoi spendere decine o migliaia di dollari all'anno solo per quello!
Oltretutto, anche se un tool potenziato da IA fosse possibile oggi, e per costo basso o nullo... perché mai un cliente dovrebbe comprare la tua consulenza SEO se potrebbe lei stessa usare quel tool?
Fortunatamente per consulenti SEO, agenzie web e tutta la banda - e sfortunatamente per i proprietari dei siti web - quel tool ancora non esiste e non esisterà per un bel po' di tempo.
Quando fai una consulenza SEO, non stai vendendo un report generato automaticamente. Stai vendendo la tua conoscenza su come interpretare i dati esposti dagli strumenti. Stai vendendo la tua esperienza su come le cose andrebbero migliorate. E quell'esperienza non nasce da una semplice check-list, e spesso non è una risposta "una misura buona per tutti": ogni cliente ha limitazioni in tecnologia e budget.
Magari dipendono fortemente da un CMS o piattaforma e-commerce che non permette loro di impostare redirect, o editare dati strutturati, o correggere una brutta navigazione a faccette. Allora devi sapere come girarvi attorno con URL canonici, regole nel robots.txt, etc... non ti puoi fermare alla check-list.
Come produttori di uno strumento SEO, con SEO Studio ci prodighiamo continuamente per fornire il miglior equilibrio tra quantità di dati mostrati di default, e facilità d'uso del prodotto, e così via.
Un malinteso di lunga data
Nello scrivere questo articolo mi sono reso conto c'è un malinteso di lunga data tra produttori di tool per SEO e utenti SEO.
Creare un software che emuli il cervello umano e terribilmente difficile. Allora i programmatori fanno qualcosa di meno sofisticato, ma gli utenti assumono che le cose siano diverse.
Prendiamo per esempio il problema del thin content. Supponiamo che la funzione desiderata sia un report che elenchi tutte le pagine con contenuti sottili.
Il modo corretto per farlo sarebbe "parsare" l'HTML di ogni pagina, rimuove tutte le parti del boiler-plate (non è banale costruire uno strumento che lo riconosca sempre in modo affidabile), poi estrarre il testo puro del contenuto principale della pagina, contarne le parole, decidere se sono troppo poche (non sempre possibile senza contesto)...
Questo è simile a quanto in buona parte fa la funzione "Leggibilità" di Visual SEO Studio (tra tante altre cose), e non è così semplice da realizzare.
Allora i produttori di vecchi tool fecero ricorso a strade alternative:
- invece di estrarre il testo puro del solo contenuto principale estrarlo tutto - menu e footer e tutto il resto incluso - e ordinare per ordine crescente di numero di parole contate.
Il software non può sapere se i primi risultati sono effettivamente contenuti sottili: il conteggio potrebbe essere basso perché il template è leggero, o potrebbe essere alto perché il template è pesante, non sa quali parole appartengano al contenuto principale.
Sta all'utente controllare.
Ma l'utente del tool assume che il conteggio delle parole sia un fattore di ranking. - oppure invece di computare il rapporto tra testo e HTML di tutta la pagina, perché assume che le pagine con contenuti sottili abbiano un rapporto basso, e mostra la lista in ordine crescente.
Il software non può per certo sapere se i primi risultati siano dei contenuti sottili.
Sta all'utente controllare.
Ma l'utente del tool assume che il rapport testo/HTML sia un fattore di ranking.
Conclusioni
Fare SEO professionalmente non è solo adottare risposte "una misura buona per tutti", o inoltrare un report generato da un tool SEO senza alcuna revisione..
I professionisti dovrebbero approfondire di più e conoscere qual è la ragione dietro a ciascuna raccomandazione SEO, saper capire se sono ancora valide, quando ha senso applicarle al proprio caso, se mai hanno senso, ed essere in grado di adattare le limitazioni imposte da tecnologia, budget e tempo.
Spero con questo articolo di aver fornito gli strumenti intellettuali per migliorare nei principianti comprensione e professionalità.
Questa non vuole essere in alcun modo una lista esaustiva, ho voluto concentrarmi solo sulle cose più dibattibili, occasionalmente anche trattando alcuni miti SEO duri a morire.
Pensi manchi qualcosa valga la pena di discutere e la vorresti aggiunta? Parla!