Le regole del digitale stanno cambiando.
O sei visibile o sei fuori. Noi ti aiutiamo a raggiungere i clienti giusti — quando ti stanno cercando.
Contattaci ora →
Google aggiorna le linee guida sull’uso del tag canonical con JavaScript, ma restano dubbi sull’efficacia di queste nuove indicazioni per risolvere i problemi di indicizzazione.
Google interviene sul caos dei tag canonical generati via JavaScript, causa di grossi problemi di indicizzazione. Le nuove linee guida ufficiali, però, appaiono più come una toppa che una soluzione reale. Anziché semplificare il proprio sistema di rendering, Mountain View sembra scaricare la complessità e la responsabilità interamente su sviluppatori e professionisti SEO, lasciando irrisolto il problema di fondo.
Canonical e JavaScript: Google prova a mettere ordine, ma il caos resta
Ti è mai capitato di vedere Google scegliere una versione della tua pagina che non avresti mai voluto in SERP, nonostante i tuoi sforzi per impostare il tag canonical corretto?
Se lavori con siti che fanno un uso massiccio di JavaScript, come quelli basati su React o Vue, la risposta è quasi certamente sì.
E la colpa, a quanto pare, è di un pasticcio tecnico che si consuma proprio sotto il naso del Googlebot, un problema che Big G ha finalmente deciso di affrontare aggiornando le sue linee guida ufficiali.
Il nocciolo della questione è un vero e proprio sdoppiamento di personalità nel processo di indicizzazione.
Quando Googlebot visita una pagina, la “legge” due volte: la prima volta analizza il codice grezzo, così come arriva dal server; la seconda volta, dopo aver eseguito tutto il JavaScript, analizza la pagina renderizzata, quella che vedrebbe un utente.
E qui scatta la trappola: se nel codice iniziale c’è un tag canonical che punta a un URL e il JavaScript, una volta eseguito, ne imposta un altro, il motore di ricerca riceve due segnali contrastanti.
Un segnale schizofrenico che manda in tilt la sua capacità di decidere quale sia la pagina “ufficiale”.
E così, mentre tu ti arrabatti a capire perché Google ignora le tue indicazioni, Mountain View finalmente si decide a parlare.
Ma la loro “soluzione” è davvero la panacea di tutti i mali?
Le “soluzioni” ufficiali: una toppa sul problema?
Di fronte a questo caos, Google mette sul tavolo due opzioni. La prima, definita come l’approccio preferibile, consiste nell’assicurarsi che il tag canonical presente nel codice iniziale sia identico a quello che verrà generato dal JavaScript. In pratica, una coerenza totale tra prima e dopo il rendering. La seconda opzione, una sorta di piano B per chi non può garantire questa coerenza, è ancora più drastica: non inserire alcun tag canonical nell’ e lasciare che sia esclusivamente il JavaScript a farsene carico.
Sulla carta, sembra logico.
Ma la domanda sorge spontanea: perché Google ci ha messo tanto a chiarire una dinamica così fondamentale, lasciando per anni sviluppatori e professionisti SEO a navigare a vista?
Questo aggiornamento, come descritto da Search Engine Journal, sembra più un modo per mettere una pezza e scaricare la piena responsabilità sugli sviluppatori, piuttosto che un vero tentativo di semplificare un processo di rendering che resta intrinsecamente complesso e opaco.
Tutto chiaro, quindi?
Non proprio.
Perché questo aggiornamento non arriva da solo, ma si inserisce in un quadro più ampio di “chiarimenti” che, a guardar bene, sollevano più dubbi che certezze.
Un gioco di specchi più grande
Questa mossa sui tag canonical non è un caso isolato. Si affianca, infatti, a recenti avvertimenti sull’uso del tag noindex con JavaScript.
Google ha messo nero su bianco che se il noindex è presente nell’ iniziale, il bot potrebbe decidere di non eseguire affatto il rendering, ignorando qualsiasi tentativo successivo del JavaScript di rimuovere tale direttiva.
In altre parole, l’ “vince” sempre quando si tratta di bloccare l’indicizzazione.
Mettendo insieme i pezzi, emerge un quadro inquietante: Google sembra dire “gestite voi la complessità che il nostro stesso sistema di rendering a due fasi crea”.
Invece di offrire strumenti più trasparenti o un crawler più intelligente, ci fornisce una serie di regole bizantine.
Siamo sicuri che queste “best practice” siano pensate per aiutarci davvero, o non sono piuttosto un modo per giustificare i futuri errori di indicizzazione, potendo sempre dire: “ve l’avevamo detto noi come fare”?
Google ci dà istruzioni per appendere quadri dritti in una casa storta. Le fondamenta restano quelle. Noi continuiamo a sistemare le crepe con attrezzi sempre nuovi. È il lavoro dell’artigiano, in fondo.
Praticamente ci danno istruzioni per aggirare i loro bug. Un classico. Tutto sto casino per un tag. Mi chiedo se il mio lavoro sia solo mettere toppe ai sistemi degli altri.
Melissa Benedetti, definire “lavoro” il continuo rammendo dei loro errori è una notevole acrobazia verbale. Siamo diventati i sarti di un imperatore digitale nudo che si diverte a strapparsi i vestiti, non trovi?
Melissa Benedetti, ci pagano per applicare cerotti su sistemi malati, una professione curiosa. La vera domanda è: la malattia è un bug o una feature?
Elisa Marchetti, ottima riflessione. Se è una feature, la “malattia” è il modello di business stesso e noi siamo parte integrante del suo funzionamento. Una consapevolezza che non è sempre comoda da accettare mentre si lavora.
Melissa Benedetti, più che curare una malattia, mi sembra che stiamo costruendo la cattedrale del bug. E le vetrate sono splendide, viste da dentro.
Invece di sistemare il loro motore, ci insegnano come lavorare attorno ai loro difetti.
Daniele Palmieri, la loro pigrizia è diventata il nostro mestiere. Una carriera brillante.
Daniele Palmieri, ci addestrano a navigare nel loro caos. Una toppa dopo l’altra. L’idea di un errore di rendering che vanifica mesi di lavoro mi mette i brividi. A chi risponderemo poi?
Nessuna sorpresa: il labirinto è la loro architettura, non un nostro errore di percorso.
Ci offrono istruzioni, non soluzioni. Scaricano la complessità su chi crea valore. È questo il modello di partnership che desideriamo per il futuro del web?
È ammirevole come ci forniscano gli strumenti per rimediare alle proprie carenze strutturali, presentandoli come un progresso. Trasformano il loro debito tecnico in un nostro dovere. Quando inizieremo a fatturare loro la consulenza?
@Patrizia Bellucci, la sua domanda sulla consulenza è lecita. Ci appioppano il loro caos tecnico e lo chiamano supporto. Quando pagano il disturbo?
Scaricano il loro debito tecnico e lo chiamano “linee guida”. La vera innovazione è farci lavorare gratis. Business as usual.
@Greta Silvestri Ci danno le istruzioni per riparare la loro nave che affonda. Intanto i miei progetti restano in balia delle onde. Quando smetteranno di farci pagare per i loro errori?
@Greta Silvestri Hai detto tutto. Ci passano le loro rogne e le chiamano “best practice”. Il bello è che c’è gente che ancora li prende sul serio.
Ennesima pezza che sposta lo sbattimento lato nostro, mentre la causa del problema, ovvero il loro sistema di rendering, rimane intoccata. Alla fine, paghiamo sempre e solo noi le loro inefficienze.
@Filippo Villa Loro costruiscono il labirinto, a noi la responsabilità di trovare l’uscita. Inaccettabile.
@Filippo Villa Lamentarsi delle loro inefficienze è una perdita di tempo. Ogni nuovo ostacolo è un filtro che premia chi si adatta più in fretta, lasciando indietro chi si attarda a discutere le regole del gioco.
@Veronica Valentini Il tuo punto sul “filtro” è corretto, ma non seleziona il migliore. Seleziona chi è più bravo a rammendare la rete che loro stessi bucano. Più che un’evoluzione, mi sembra una gara a chi tappa più falle velocemente.
Che generosi da parte di Google, ci offrono una toppa per un buco che hanno creato loro. Invece di sistemare le fondamenta della casa, ci vendono il nastro adesivo. Mi chiedo quando inizieranno a farci pagare anche per quello.
@Laura Bruno Più che nastro adesivo, è un test per misurare la nostra soglia di sopportazione prima di arrenderci e comprare i loro servizi prioritari. Io mi sento già un ottimo topo da laboratorio.
@Paolo Pugliese Topi da laboratorio, hai detto bene. E con queste “guide” ci stanno solo insegnando a premere il pulsante sbagliato più in fretta. La cosa triste è che funzioniamo ancora a formaggio.
@Laura Bruno Bellissima l’immagine del nastro adesivo. In fondo, ci spingono a diventare più abili nel nostro lavoro, anche se a volte vorrei solo costruire qualcosa senza che il manuale di istruzioni cambi ogni settimana.
Continuare a discutere di questi tecnicismi è una perdita di tempo. Se una pagina non viene indicizzata, è un asset inutile. La vera soluzione è costruire pagine semplici che funzionano. Bisogna puntare al risultato, non al processo.
@Eva Testa L’idea delle “pagine semplici” è deliziosa, peccato che il business richieda architetture che non si disegnano su un post-it. Questa semplificazione è un ottimo alibi per ignorare chi detta davvero le regole del gioco e continuare a lamentarsi.
@Alessandra Lombardi Non è un alibi, è un dato di fatto. Si costruiscono cattedrali ingestibili per il business, poi si piange sul canonical. Logico, no?
@Eva Testa Il risultato arriva curando il processo, altrimenti è solo un bel soprammobile inutile.
Google ci chiede di tappare una falla con del nastro adesivo. È la solita delega di responsabilità per un loro problema strutturale. Si pretende precisione da noi, ma la base rimane instabile.
@Walter Benedetti Scaricano il problema su di noi, è più economico. Loro non sistemano il loro motore di rendering e noi perdiamo tempo. Il solito modo per farci da beta tester gratuiti.
Walter, caro, ti stupisci ancora? È il solito giochino del cerino in mano: loro creano il casino e poi ci danno istruzioni, pure scritte male, per pulire. A me pare un diversivo.