Ciao e benvenuto alla edizione #41 della EV SEO newsletter, nella quale ho raccolto le novità e i contenuti SEO più interessanti (o almeno quelli che ho trovato tra i tanti che ho letto) delle ultime due settimane abbondanti visto che nel mentre sono stato qualche giorno in ferie! Google ha fatto piuttosto rumore e c’è molto da dire: rompo gli indugi e ti auguro una buona lettura.
Parliamo delle migrazioni di dominio (e di alcuni comportamenti meno noti di Googlebot)
Come riportato dal Search Engine Roundtable John Mueller ha risposto in modo interessante ad un utente che, nell’ambito di un Google Webmaster Hangout, gli ha chiesto “una migrazione di dominio può influenzare la SEO del mio sito?“. Ecco la risposta tradotta:
Di solito si. In passato era molto più evidente: spostare un sito da un dominio all’altro poteva fare si che ci volessero mesi perché le cose si “sistemassero” sul motore di ricerca.
Oggigiorno i nostri sistemi sono molto migliorati: in buona sostanza se durante la migrazione vengono seguiti pedissequamente i passi descritti nella nostra documentazione (che puoi trovare qua N.D. Emanuele) questo genere di attività può richiedere semplicemente un giorno o due, con una situazione sulle SERP che viene “trasferita” senza subire variazioni significative.
Detto questo le migrazioni di dominio o altre grandi cambiamenti nella struttura delle URL di un sito sono sempre situazioni piuttosto delicate per quel che mi riguarda. Il mio consiglio è di stare molto attenti a ciò che si fa, seguendo in modo attento le guide nel nostro help center. Ci sono anche diversi articoli molto completi sull’argomento con checklist e quant’altro: è una buona idea utilizzare questo genere di strumento.
“…” Seguire una checklist fa si che, in caso di problemi, sia possibile controllare cosa è stato fatto e cosa no: avere questa possibilità può risultare davvero utile.
In buona sostanza se si fa tutto in modo corretto una migrazione di dominio “fa effetto” in pochi giorni e può addirittura sembrare molto semplice da fare. Il problema è che ci sono tantissime cose che si possono sbagliare e ci sono tantissimi tipi differenti di migrazione, alcuni molto più complicati di altri per Google da processare.
Mueller ha ragione nel dire che le migrazioni sono veri e propri “campi minati” dove è molto, molto facile farsi del male. Il suo consiglio, da me parafrasato, di “tenere una lista delle cose da fare segnandosi quelle fatte e quelle non fatte” è oro puro ma, come i mitici commenti al codice, è tra quelle best pratice spesso sacrificate in nome della fretta e dei budget troppo bassi.
A naso, dopo anni di consulenze, non ho problemi nel dire che almeno il 50% dei problemi da chi ha perso traffico e quindi chiede una mia consulenza proviene dalla gestione approssimativa di migrazioni consapevoli e inconsapevoli: nel secondo caso si tratta, il più delle volte, dei classici “redesign” durante i quali viene ignorato il cambiamento della struttura delle URL con risultati tendenzialmente disastrosi. Oltre a perdere per strada segnali quali collegamenti semantici tra le pagine e/o la struttura che distribuisce il PageRank quello che accade è che Google quando vede un cambiamento radicale in un sito fa analisi molto approfondite , andando in alcuni casi a fare le pulci in posti dove, per qualche motivo fortuito, ancora non era andato ad analizzare. Questo può far si che un elemento fino ad oggi sconosciuto o ignorato da Google, post cambiamento URL, divenga un moltiplicatore negativo nel computo relativo al posizionamento delle pagine. In poche parole è stato svegliato il proverbiale “can che dorme”. E’ un discorso molto complesso sul quale vorrei tornare, in futuro, a parlare in altre sedi. Ti basti però sapere che il rischio non è solo legato all’errore, almeno secondo me.
Detto questo se ti capiterà di fare una migrazione ti consiglio di mettere nei tuoi segnalibri, per poter consultare i passaggi “base”, il già citato documento di Google chiamato “Panoramica sugli spostamenti di siti con modifiche agli URL“ che mi pare essere piuttosto completo e ben fatto. Adesso vorrei però darti una lista di cose che non leggo mai nelle guide in giro nella rete ma che sono, secondo la mia esperienza, molto importanti:
- Tieni sempre una copia di backup del crawl del vecchio sito: un crawl, al contrario della semplice “lista di tutte le URL” che mediamente le guide consigliano di conservare, contiene informazioni che possono risultare molto interessanti anche in futuro, come ad esempio:
- la presenza di implementazioni a codice che influenzano il comportamento di Googlebot quali rel=”canonical”, meta refresh, noindex, nofollow e altri elementi nel codice che potrebbero sfuggire e non essere trasferiti durante la migrazione, determinando un cambiamento inconsapevole nella struttura;
- la mappatura della struttura di interlinking con indicazioni specifiche su pagine che ad esempio non esistono più o non sono più a quella URL (ci torniamo tra poco);
- una serie di statistiche importanti per un confronto pre e post migrazione, dalla presenza di determinati elementi semantici alle statistiche relative alla velocità di risposta del server o al numero e alle caratteristiche dei file multimediali;
- Prima di fare la migrazione pulisci la struttura delle URL: una migrazione, come il passaggio ad HTTPS, può fare da trigger ad un cosiddetto deep crawl, ovvero ad una scansione approfondita del sito da parte di Google, facilmente riconoscibile semplicemente dal pannello relativo al crawling della Search Console per il picco anomalo di richieste svolte in un solo giorno: di solito si tratta di una scansione multipla di ogni singola pagina del sito o comunque di ogni singola URL segnalata in struttura (e a volte da link esterni).
Per questo motivo è un ottimo momento per far vedere quanto “siamo bravi” presentando una struttura pulita: prima di tutto evitiamo 301 e 404 in struttura, ovvero link interni che puntano a risorse che rispondono con uno di questi status code HTTP. ATTENZIONE: avere su di un sito redirect e 404 è normale e sano ma sono strumenti pensati per controllare e definire il traffico dall’esterno del sito, non dall’interno del sito stesso per il quale esistono soluzioni più pulite. Ad esempio- invece di un 301 in struttura bisogna far puntare il link alla URL giusta direttamente;
- invece di puntare ad una pagina non esistente bisogna che il link faccia riferimento ad una pagina effettivamente presente o che il link sia rimosso;
Ci sono naturalmente tantissime implementazioni che influiscono sulla struttura e sulla interpretazione di essa da parte di Googlebot, come ad esempio il rel=”canonical”, ma 301 e 404 in struttura sono più subdoli perché la appesantiscono senza un riscontro veramente diretto e pesante come può essere, ad esempio, una pagina che scompare dalle SERP per un canonical sbagliato. Nella mia esperienza sono aspetti molto trascurati che però, soprattutto su siti di grandi dimensioni, impattano sulle performance SEO.
Un altro aspetto che è buona cosa migliorare nell’ambito di un deep crawl causato da un cambio di dominio sono le prestazione del server: visto che per altro la frequenza e “l’intensità” di crawl sul nostro sito da parte di Googlebot (il cosiddetto crawl budget) si basa tra le altre cose su quanto Googlebot determina di poter tassare il server senza farlo sedere, ad esempio iniziando a ricevere errori 500 come risposta alla richiesta di una pagina. Se il server del vecchio sito è messo in difficoltà dal traffico in arrivo sulla macchina questo è un ottimo momento per fare un upgrade: sui nuovi domini nulla è deciso a priori, ed è più facile fare una buona “prima impressione” piuttosto che fargli “cambiare idea”;
- Prima di fare la migrazione valuta la presenza di contenuto inutile: l’idea è che, vista la possibile complessità e lungaggine dell’analisi di Google del sito migrato sia meglio fargli perdere meno tempo possibile. Questa è la semplificazione estrema di un argomento veramente troppo complesso da esaurire nelle poche righe di una newsletter (da mesi scrivo una guida e vi ho dedicato uno speech al Serious Monkey 2019) ma, in generale, prima di fare una migrazione è una buona idea controllare:
- L’eventuale presenza di “spazi infiniti”, ovvero di pagine che vengono (di solito) create ricorsivamente per errori nel codice, come ad esempio un link relativo al posto di uno assoluto in un elemento di template come una breadcrumb;
- L’eventuale nei CMS di archivi e/o pagine di template inutili, come ad esempio gli archivi autore in un blog mono autore, le media pages di WordPress ma anche tassonomie duplicate/simmetriche;
- L’eventuale presenza di contenuto del quale il sito potrebbe fare a meno: la regola aurea della SEO, per quanto riguarda la struttura di un sito web, è “meno pagine possibili che siano il più possibile importanti per i tuoi utenti e per Google” e, applicandola con un po’ di buonsenso, saprai cosa fare senza dilungarmi troppo. Ricordati che possono esistere pagine che ad esempio non fanno traffico, e quindi sembrano inutili, ma che raccolgono link in ingresso o che convertono perché, pur non rappresentando un punto d’atterraggio dai motori di ricerca, fanno parte di un percorso esperienziale di valore del quale magari non sei a conoscenza. Rifletti attentamente sui contenuti del tuo sito (e attendi con fiducia il remake del mio speech al Serious Monkey che Enrico Altavilla mi ha dato gentilmente la possibilità di ricreare su YouTube);
- Tieni d’occhio le statistiche di crawling e aiuta Google a raggiungere le parti “in ombra” del sito: può capitare, per diversi motivi, che Googlebot non arrivi facilmente a “vedere” alcune parti del sito perché ad esempio troppe profonde nella struttura per il crawl budget del vecchio sito. Parlo del vecchio sito perché, per fare in modo che vengano “passate” le performance SEO dal vecchio al nuovo sito, Googlebot deve vedere che la pagina vecchia è stata spostata con un redirect verso quella nuova, e quindi la scansione deve avvenire nel miglior modo possibile sia nel vecchio che nel nuovo dominio. Per tenere d’occhio queste dinamiche bisogna rivolgersi ai server log, osservando il comportamento di Googlebot in relazione ad eventuali problemi di indexing: “se nel sito nuovo la pagina non viene indicizzata è perché Google non riesce a vedere la vecchia versione?“;
- Non cancellare subito la sitemap del vecchio dominio: Google ha bisogno di essere “spinto” a visitare le pagine del sito e lasciargli un riferimento dal quale arrivare a vedere che questa o quella pagina fanno un redirect è molto utile. Inoltre potrai avere la “controprova” del passaggio del posizionamento da un sito all’altro osservando le pagine indicizzate calare nella sitemap del vecchio sito. Puoi anche settorializzare le sitemap su determinate parti del sito (sezioni, tassonomie etc. etc.) per dare priorità al passaggio, mostrando prima determinate parti del sito, e per controllare in modo più specifico le parti stesse. Ricordati che la sitemap di Yoast viene generata solo se il PHP lavora: se i DNS non puntano più il vecchio dominio alla cartella del server dove risiede la installazione di WordPress Google non avrà più accesso alla sitemap.
- Per velocizzare il passaggio puoi usare alcune delle strategie descritte nella mia guida alla cancellazione di contenuti da Google, come ad esempio una bella pagina con i link alle URL reindirizzate nella vecchia struttura da passare a Google tramite la indexing API.
Rileggendo quanto ho scritto forse dovrei fare una mia versione di “guida per la migrazione” prima che qualcuno si prenda tutti i punti della lista e li scriva sul suo blog com’è successo poco tempo fa con la “versione rimescolata in inglese” del mio articolo sul cancellare contenuti da Google definitivamente, apparso in un famoso blog di un famoso tool in inglese… firmato da un altro. La meraviglia!
Tristi vicissitudini editoriali a parte spero che questa lista possa servirti non solo per la tua prossima migrazione ma anche a farti ragionare “fuori dagli schemi” comprendendo meglio la “schematicità” di Google.
Il parser di Google del robots.txt è diventato opensource… dopo una pulizia delle funzioni supportate
E’ chiaro che Google attenda sempre che io vada in ferie per rilasciare bombe tipo questa descritta sul loro Webmaster Blog, dove in buona sostanza hanno reso pubblico (e opensource) il comportamento di Googlebot nei confronti dei file robots.txt, uno standard creato da Martjin Koster nel 1994 per limitare l’accesso del suo sito ai crawler, i quali stavano mettendo in seria difficoltà il suo server (probabilmente il suo computer di casa o dell’università).
Il robots.txt, come riportato da Google nel suo articolo, non è un vero e proprio standard di Internet ma è uno standard de facto, in quanto tendenzialmente onorato dai vari software di crawling tra i quali quelli dei motori di ricerca.
Dai fatto, leggendo il codice (che puoi trovare qui), è chiaro che, come dichiarato successivamente nell’articolo di Google, che è stato tagliato il supporto a diverse funzioni, ora deprecate, prima tra le quali il “noindex”. Nel codice troviamo dichiarati i 4 campi principali e un contenitore per il codice “estraneo” :
// Generic highlevel fields.
USER_AGENT,
SITEMAP,
//Fields within a user-agent.
ALLOW,
DISALLOW,
// Unrecognized field; kept as-is. High number so that additions to the
// enumeration above does not change the serialization.
UNKNOWN = 128
Come indicato “allow” e “disallow” sono sottocampi del campo “user_agent” e come tali vanno utilizzati.
Leggendo i commenti si evince che Google, nel suo specifico caso:
- Fa il parsing anche di stringhe dentro file robots.txt dove è utilizzato uno spazio invece che un “a capo”, con le dovute eccezioni (per favore vai a capo!);
- Fa il parsing anche di file con elementi anomali facendo linting;
- Richiede che ogni singola url non sia più pesante (lunga) più di 2kb;
- Normalizza “index.htm” e “index.html” con il trailing slash;
- Non riconosce nulla al di fuori dei 4 campi sopra specificati;
Google ha dedicato un articolo sulle funzionalità che verranno deprecate dal 1 settembre 2019 sul suo Webmaster Blog. Citando il fatto che, non essendo documentate, le percentuali di implementazione delle stesse fossero minore dello 0,001%, viene a meno il supporto per le direttive:
- la direttiva “noindex“, per il quale si può usare la x-robots-tag come header response o l’implementazione via codice HTML;
- la direttiva “host“, con la quale si poteva specificare se il motore di ricerca dovesse utilizzare la versione “con www.” o “senza www.”, la quale nel caso di Google è meglio specificare dalla search console o forzando semplicemente il redirect da una versione all’altra, cosa che andrebbe sempre fatta per non avere il sito duplicato nel 99% delle impostazioni server utilizzate dagli hosting più utilizzati;
- la direttiva “crawl-delay“, che sinceramente non sono sicuro che Google abbia mai onorato ma che, con gli altri motori di ricerca, fa si che i crawler abbiano un ritardo, espresso in secondi, tra una richiesta di URL e quella successiva. Anche in questo caso c’è la possibilità di specificare una delay (o per meglio dire una ratio) direttamente da Search Console, anche se il mio consiglio è lasciarla decidere a Google. Riporto lo stesso come accedere al pannello per completezza:
Se ti interessa il documento puntuale che illustra nel dettaglio l’atteggiamento di Googlebot verso il sistema robots.txt puoi consultare questa pagina.
Al margine di queste considerazioni tecniche una cosa molto importante e interessante è che Google vuole proporre uno standard per il robots.txt allo IETF (puoi leggere una bozza incompleta della proposta qui sul loro blog), organizzazione indipendente e open (come la più famosa Internet Society) che in buon sostanza si occupa di definire standard per il web. Google dice di avere proposte basate su 20 anni di esperienza con il loro crawler, affrontando alcuni punti che ti riporto qui tradotti:
– Qualsiasi protocollo basato su URI può usare robots.txt. Ad esempio può essere usato, oltre che per HTTPS, per FTP e CoAP;
– Gli sviluppatori devono fare il parsing di almeno i primi 500 kibibytes. Definire un tetto massimo alla grandezza del file fa si che le connessioni non stiano troppo a lungo aperte, alleviando il carico sui server (so che è un po’ confusa come frase ma è ciò che è stato detto/pubblica N.D. Emanuele);
– Un tempo massimo di caching di 24 ore o, se disponibile, un valore di durata della cache danno ai proprietari dei siti la flessibilità di poter aggiornare il loro file robots.txt quando vogliono senza che i crawler carichino eccessivamente i server con delle richieste verso il file robots.txt. Ad esempio, nel caso di HTTP, i Cache-Control headers possono essere utilizzati per determinare il tempo di caching;
– La nuova specifica dice che, nel caso in cui un file robots.txt che era precedentemente accessibile da un crawler risulta improvvisamente inaccessibile per problemi al server che ospita il file le pagine che il crawler sapeva essere in disallow da precedenti scansioni verranno ignorate comunque ignorate per un lungo periodo di tempo;
Tutte proposte che, dal mio umile punto di vista, hanno molto senso (anche se, devo ammetterlo, mi sono dovuto leggere cosa fosse un kibibyte). Detto questo, andando oltre gli annunci e lo storytelling, il “gesto” di Google, ovvero la pubblicazione open-source del crawler e la proposta per questo standard hanno, dal mio punto di vista, tre principali implicazioni:
- Mettersi in prima linea come policy maker cercando, di fatto, di arrivare a definire un altro standard senza chiedere nulla a nessuno, come nel caso di HTTPS;
- Ripulire, almeno un poco, la sua immagine di azienda braccata dall’antitrust per la poca trasparenza tecnologica ed etica;
- Sfruttare competenze esterne per poter cercare talento e acquisire tecnologia in modo gratuito;
Forse sono troppo cinico ma ormai sono sempre molto dubbioso e si, un poco prevenuto nei confronti di Google come azienda. Intendiamoci: non è certamente la sua prima venture nell’open source e in passato, con tecnologie quali il Tensorflow, ha pubblicato cose molto interessanti ma, al contrario di quello che mi sarei aspettato, formare Alphabet e dividere in modo più netto le azienda ha abbassato la qualità, almeno a livello etico e comunicativo, della Google Search. Se questa iniziativa riguardante il robots.txt fosse stata fatta 10 anni fa avrei pensato altro, sicuramente avrei avuto una percezione più positiva del tutto, ma ora mi è molto difficile farlo, ma non voglio dilungarmi troppo sulla questione in questa sede. Mi piacerebbe però invitare ad un confronto qualcuno che la pensa in modo molto differente da me, se ci sei batti un colpo!
Fare ricerca e imparare nell’ambito della SEO è difficile perché i SEO rendono difficile farlo
Mentre scandagliavo i miei feed alla ricerca di qualcosa di interessante che mi potesse essere sfuggito sono capitato in questa breve quanto “necessaria” conversazione dove il buon Bill Slawski dice una cosa giustissima. Prima di dirti quale ti mostro la versione “integrale” della conversazione:
L’ultimo tweet, a grandi linee, può essere tradotto così:
Ci sono persone che condividono tante ricerche approfondite mischiandole con la fantasia, come ad esempio “come ottimizzare una pagina per RankBrain”. Dubitate di loro quando lo fanno. Vogliono il vostro click e si inventeranno cose per ottenerlo.
Slawski ha dato una direttiva molto utile ma anche molto triste, perché assolutamente necessaria. In un ambiente come la community SEO internazionale, quindi italiana e non nel nostro caso, dove ci dovrebbe essere dello scrupolo nel mentire al prossimo, se non altro perché tendenzialmente si ha davanti una platea più preparata e con gli strumenti per separare il grano dalla pula come direbbe il buon Amin, purtroppo l’esercizio del dubbio rimane vitale per la sopravvivenza professionale e pratica. Questo perché i canali di divulgazione, e lo dico da avido lettore e osservatore, sono letteralmente inondati di merda e di interessi. Dico professionale e pratica perché fare SEO è in molti casi una cosa dedicata, soprattutto in un mondo dove tante aziende, ahimè, tendono a incentrare troppo su di un canale incerto e a tratti imprevedibile come il traffico proveniente dai motori di ricerca il business, finendo bruciati o addirittura fregati da un brusco calo di performance dovuto, il 99% delle volte, da azioni di “auto-sabotaggio” compiute in modo più o meno inconsapevole.
Certamente è più probabile che semplicemente venga “venduta aria fritta“ in una confezione riportante la dicitura “trucchi SEO” o “la strategia definitiva“, e l’unica cosa che si fa male è il portafoglio del malcapitato o il tempo che avrebbe potuto impiegare nello studiare qualcosa di veramente meritevole, ma “l’offesa”, in senso sociale, resta. E’ una cosa che personalmente mi atterrisce e che ha fatto scappare diversi colleghi, lo so per esperienza diretta, dalla community stessa.
Il mio invito, caro lettore, è (almeno in ambito SEO, ma in generale non è un atteggiamento scorretto) di dubitare sempre e comunque, di tutto e di tutti, anche di me naturalmente. Non dico di dubitare la buonafede del prossimo sistematicamente, quella è una questione di indole personale credo, quanto mettere in dubbio la conoscenza quando ci viene proposta. Non parlo del “sperimenta, sperimenta sperimenta” che personalmente mi ha rotto i coglioni, sempre per continuare col francese, nel suo pressapochismo. Parlo di andare a fondo, oltre all’articolo scritto dal SEO, inteso come professionista, che non è altro che un contadino che pensa di avere studiato. La SEO, così come l’agricoltura, è un mestiere dignitoso, impegnativo e affascinante, sicuramente pieno di soddisfazioni. Ma non è scienza nucleare. Come il contadino il SEO osserva ed esperisce, distilla una conoscenza empirica da un sistema chiuso del quale i suoi ingegneri distribuiscono perlopiù pressapochismo e vere e proprie falsità per sopperirne i limiti e limitarne l’utilizzo “scorretto” (dal loro punto di vista perlomeno). Ci tengo a parlarti di questa mia idea perché a volte mi pare di capire che tanti colleghi parlino per alimentare un “sentirsi professore” o “sapiente” come se i SEO fossero parte di un circolo accademico, come se facessero scienza, mentre la SEO è tutto tranne che scienza e i SEO sono tutto tranne che professori, me compreso. Siamo contadini molto fortunati perché non ci bruciamo al sole (o almeno io ho sempre le tende tirate).
Attenzione: fare teorie, parlare delle proprie idee e delle proprie osservazioni è importante e anzi vitale in un contesto del genere. L’importante è che queste rimangano ancorate perlomeno alla propria esperienza e non alla propria fantasia o ai propri interessi, perché si vuole vendere un prodotto o chissà cos’altro.
Per concludere “andare a fondo” per me significa, dopo essere venuto in contatto con una nuova nozione, fare ricerca, confrontare l’esperienza mia e di altri, confrontarmi e si, nel giusto limite e ordine, sperimentare un poco. Creare e assorbire conoscenza è un processo tutt’altro che passivo e richiede impegno. Se c’è una cosa che mi ha permesso di crescere molto professionalmente (parlo di risultati concreti sia SEO che business) è proprio questo mindset, e per questo te ne ho voluto parlare. Spero che nessuno si senta preso di mira dalle mie parole perché davvero non avevo in mente nessuno di particolare. Se stai leggendo e ti senti preso in causa tra chi condivide falsità o approssimazione beh, riflettici su, o almeno ti consiglio di farlo.
Altri articoli interessanti
Ecco una carrellata di articoli interessanti che non ho voluto/potuto approfondire e qualche curiosità che vorrei segnalarti:
Firmare i propri contenuti è importante a livello SEO?
Ha senso, a livello SEO, usare uno pseudonimo per firmare i propri contenuti, ad esempio nel blog? E’ una domanda alla quale ha risposto John Mueller durante un English Google Webmaster Central office-hours hangout rispondendo, di fatto, come avrei risposto io: nel mondo reale ti fideresti di più di un nome conosciuto in un campo sensibile, ad esempio di un dottore in campo medico o di un analista finanziario in campo appunto finanziario, o di uno pseudonimo o un “redazione del sito XXX”? Contando che Google vorrebbe giudicare i contenuti come li giudicherebbe un essere umano medio, o “la media di tutti gli esseri umani“ come piace dire a me, la risposta è molto semplice.
“Ok Emanuele tutto molto bello, ma che impatto ha sulle SERP “numericamente” questa cosa?”. Ecco la risposta: boh! Non lo sa Mueller e con ogni probabilità non lo sa precisamente nessuno, ma va bene lo stesso: questa è la domanda sbagliata da farsi. La domanda è “vale la pena in generale di avere una firma importante e riconoscibile?“. La risposta per me è si: da una parte c’è questo plausibile impatto a livello SEO ma c’è anche un impatto più pratico legato al fatto che legare un sito ad un nome autorevole tende a catturare la fiducia dei propri utenti, con maggiore possibilità che essi tornino a visitare il nostro sito web e che compiano azioni che richiedono fiducia come l’acquisto, diretto o su di un sito affiliato. Come ho ripetuto più volte se si fa una cosa per la SEO che ha un solo risultato, come fare un link per il solo PageRank, probabilmente si sta sprecando tempo che si potrebbe utilizzare per fare qualcosa di più sinergico e olistico riferito al “sistema business” di un progetto web ad esempio. Io ad esempio riportando questa domanda ho voluto chiarire trasversalmente diverse cose in questo piccolo paragrafo, spero potrà esserti utile;
C’è modo di recuperare traffico dal FAQ Schema?
Apparentemente, dico così perché non ho ancora avuto modo di testare, è possibile inserire dei link nel FAQ Schema in modo che vengano stampati nel rich result in SERP. Questo articolo di Lily Ray, oltre a presentare questa interessante possibilità, consiglia anche di inserire lo UTM tagging per tracciare i link dallo snippet inserendo il codice nel solo Json-LD, pratica che sinceramente non mi suona benissimo: solitamente nelle guidelines per i dati strutturati ciò che viene stampato nella pagina e ciò che viene inserito nei Json-LD deve essere assolutamente identico. Personalmente sarei molto cauto con i link e ancora di più col tagging, per il quale forse è più sicuro mandare l’utente su di un hop quale un redirect per tracciarlo, anche se non penso che Google gradirebbe troppo pubblicare un link con redirezione in SERP troppo a lungo… bisogna, in questo caso, fare dei test. Buon divertimento!
Google lancia place topics su Google Maps
Google lancia (o sta lanciando) la funzione place topics per Google Maps . Si tratta, in buona sostanza, di una funzione di auto-tagging delle recensioni degli utenti, la quale stampa una raccolta dei termini più utilizzati per descrivere il business recensito. Verrà stampata per i business con “una sufficiente quantità di recensioni di qualità“. Mentre sto scrivendo queste righe, il 6 luglio 2019, la feature non viene stampata neanche per attività con centinaia di review e quindi non ho potuto testarla: non mi è chiaro ad esempio se i tag di fatto sono link alle recensioni che contengono la keyword ad esempio. Detto ciò si aprono scenari interessanti per i più birichini, ad esempio forzare certe parole chiave nel mix, una cosa probabilmente più interessante che le “stelle” del voto… fai il bravo;
Non cercare il “singolo colpevole” (potresti provare però lo user testing)
“There is never one smoking gun (nella SEO di un sito colpito da un update N.D.Emanuele)” dice saggiamente il buon Glenn Gabe in uno dei suoi ultimi articoli dedicato all’analisi di un sito colpito da un major update tramite il feedback utente. Pur essendo il cruccio (e il neanche troppo recondito desiderio) di molti, trovare il singolo “colpevole” per la reazione avversa in termini SEO ad un major update di Google è uno sforzo vano ed un modo per mentire a se stessi negando il fatto che, come per ogni sito presente sul web, si può sempre migliorare da tanti punti di vista e, nel caso si venga “colpiti” da un major update, sia evidentemente giunto il momento di muoversi in questo senso. Detto ciò l’articolo di Gabe parla di user testing, esponendo una serie di interessanti riflessioni e parlando di alcune piattaforme tramite il quale è possibile fare questo genere di attività online, senza scomodare gruppi di studio o migliaia di euro di investimento, cosa molto, molto interessante (o non te l’avrei segnalata!);
Il pensiero della settimana
Barricato nel mio regno incantato di aria condizionata, con il mio corpo ormai formato al 50% dalla ricotta dei cannoli siciliani e l’altro 50% da squisito tonno rosso, ci si sente tra un paio di settimane con la prossima newsletter!
Detto ciò grazie mille per avermi dedicato il tuo tempo leggendo fino a qui! Se è la prima volta che leggi questa newsletter e non vuoi perderti la prossima, se vuoi leggere le precedenti o più semplicemente vuoi dire la tua su quanto è stato detto non devi fare altro che scrollare ancora un pochino:
Io per ora ti ringrazio nuovamente per aver letto fin qui e ti auguro un buon proseguimento