C’era un tempo in cui credevo che infarcire di tag i post di un blog WordPress fosse cosa buona.
Da sprovveduto novellino pensavo che mettere tanta carne sul fuoco, taggando un articolo in ogni possibile combinazione:
- aiutasse Google a capire di cosa parlavo
- aumentasse le possibilità di essere intercettato sulla parola chiave corrispettiva il tag.
Ignoravo un po’ di cose. 🙂
- ignoravo – o meglio, non ne avevo piena percezione – che per ogni tag creato, e a volte nemmeno usato, WordPress creasse una pagina a sé stante ;
- ignoravo che avrei dovuto evitare di servire ai miei utenti, e ai motori di ricerca, pagine inutili e senza senso: l’utilizzo di tag e categorie andava riservato a casi di reale necessità, per fornire un valore aggiunto alla categorizzazione del contenuto ;
- ignoravo cosa fosse il crawl budget, e di come determinate azioni potessero impattare negativamente su di esso.
Parliamo di oltre 10 anni fa, quando aprii Dimmicomefare.it, il blog generalista dove ho iniziato a fare esperienza, sicuro che scrivendo post su “come scaricare video da Youtube” qualcuno mi avrebbe trovato.
Poi ho conosciuto la SEO, lo studio annesso, una maggiore coscienza di ciò che facevo e di cosa fosse il web.
Quel sito è diventato quindi una grande palestra dove allenare le mie capacità di copy per realizzare articoli che qualche volta finiscono nelle parti alte delle SERP.
A parte questa premessa, quasi nostalgica, oggi resta un fatto.
Questo:
1.517 tag associati ad articoli.
La quasi totalità dei quali non ha alcun senso.
E ho già eliminato tutti quelli che non erano utilizzati in neanche un articolo.
L’occasione è quindi quella giusta per imparare a fare una buona pulizia dei tag su WordPress (e scriverci su questo post ;)).
Ecco il piano di lavoro che mi sono figurato prima di agire:
- Analisi traffico e individuazione delle pagine tag da eliminare
- Eliminazione delle pagine tag (a mano o via SQL)
- Impostazione dello status code 410 (Gone) per le URL delle pagine tag eliminate
OK, procediamo.
Analisi delle pagine tag: elimino tutto o c’è qualcosa da salvare?
Sono sicuro che tra le 1.517 voci sia tutto da buttare?
Non è che nel calderone c’è qualche tag ben posizionato su Google e tutto sommato sensato?
Per prima cosa occorre quindi dare uno sguardo su Google Analytics alle statistiche di accesso di tutte la pagine relative i tag.
Scarico CSV delle visualizzazioni di pagina negli ultimi 3 mesi e decido di salvare tutte le voci con visualizzazioni > 40.
Effettivamente c’è davvero poca roba.
Il 99% delle pagine non ha praticamente senso, considerando che quasi tutti i tag sono connessi al massimo a 1 articolo. 😲
Anche la Serach Console può offrirmi dati utili all’analisi.
Nello specifico è possibile estrapolare dalla scheda Prestazioni l’elenco di tutte le Pagine relative tag con annessi dati di clic e impressioni sui risultati di ricerca.
Integro pertanto le valutazioni dalle due fonti e tiro fuori un elenco di tag che vanno eliminati e un elenco di tag che vanno conservati (e magari valorizzati).
Eliminazione delle pagine tag (a mano o via SQL)
Ora che so cosa cestinare bisogna solo procedere.
Se gli elementi sono pochi posso lavorare a mano sul cruscotto WordPress, direttamente dal menù Articoli → Tag.
È possibile utilizzare le azioni di gruppo avendo cura di variare il numero di elementi della visualizzazione standard (di solito 20).
Per farlo, una volta sulla pagina Tag, occorre cliccare su Impostazioni schermata e inserire il nuovo numero di elementi.
Problema sui grandi numeri: è possibile gestire un massimo di 999 elementi.
Con 1.500 tag da eliminare la cosa è divenuta meno semplice e veloce del previsto.
Considerando la necessità di filtrare un po’ di elementi ho quindi deciso di gestire il tutto via phpMyAdmin.
Ho trovato un ottimo spunto su questa discussione di StackExchange: Massive Tags Remove Using MySQL.
Essenzialmente, come spiegato nel link, WordPress gestisce le informazioni di tassonomia su tre tabelle:
- wp_terms
- wp_term_taxonomy
- wp_term_relationships
Le prime due contengono i dati su termini e tassonomia, la terza le associazioni tra termini e post.
(ovviamente il prefisso wp_ va variato a seconda del nome attribuito alle tabelle durante l’installazione)
Prima di avventurarmi nell’operazione di DELETE salvo un elenco di tutti i tag che andrò a eliminare.
Mi basta fare una SELECT degli slug che saranno interessati dalla pulizia di massa:
SELECT *
FROM wp_terms
INNER JOIN wp_term_taxonomy ON wp_terms.term_id = wp_term_taxonomy.term_id
WHERE wp_term_taxonomy.taxonomy = 'post_tag' AND (wp_terms.slug <> 'non_eliminare_1' AND wp_terms.slug <> 'non_eliminare_2')
Mi conviene esportare quest’interrogazione su CSV per Excel, mi sarà utile successivamente, quando dovrò generarmi – partendo dagli slug – l’elenco di URL per cui impostare lo stato 410.
La condizione WHERE dello script è l’elenco dei tag “da salvare” e va integrata secondo le proprie necessità, anche sull’operazione di DELETE.
Lo script SQL per la pulizia di massa dei tag su WordPress è quindi il seguente:
DELETE wp_terms, wp_term_taxonomy, wp_term_relationships
FROM wp_terms
INNER JOIN wp_term_taxonomy ON wp_terms.term_id = wp_term_taxonomy.term_id
INNER JOIN wp_term_relationships ON wp_term_taxonomy.term_taxonomy_id = wp_term_relationships.term_taxonomy_id
WHERE wp_term_taxonomy.taxonomy = 'post_tag' AND (wp_terms.slug <> 'non_eliminare_1' AND wp_terms.slug <> 'non_eliminare_2')
Ricorda di eseguire un backup del database prima di lanciare lo script SQL!
Et voilà.
Aggiornando la pagina Tag di WordPress, dopo l’esecuzione dello script, mi trovo dinanzi una scena sicuramente più pulita:
Come preventivato sono rimasti solo i 40 tag che avevo deciso di salvare in fase di analisi
Impostazione dello status code 410 (Gone) per le URL delle pagine tag eliminate
C’è un’ultima questione da risolvere:
al momento attuale tutte le URL relative i Tag eliminati restituiscono un errore 404 (Not Found).
Occorre segnalare ai crawler di Google e degli altri motori di ricerca che quella risorsa che stanno cercando non esiste più, perché eliminata definitivamente.
Per questo sugli indirizzi delle pagine Tag eliminate definitivamente va impostato lo status code 410 (Gone).
Il rischio è quello di trovarsi sommersi in Search Console da segnalazioni di errori 404, che possono essere come ben noto un fattore penalizzante per il posizionamento del sito.
La via più facile da percorrere in questo caso è l’installazione di un plugin specifico per l’HTTP status in questione:
Installato il plugin lo si raggiunge dalla pagina Plugin → 410 for WordPress.
Se – come nel mio caso – i Tag (e le annesse pagine) sono molti, conviene lavorare sul box di inserimento manuale degli URL.
Ecco perché avevo tirato fuori la SELECT con l’elenco degli slug cancellati.
È tempo di dare in pasto ad Excel il file precedentemente esportato e ricavare l’elenco delle URL ora mancanti.
La procedura è banale:
- aggiungo una colonna di fianco quella del dato slug
- imposto sulla prima cella vuota la formula
="https://www.miosito.xx/tag/"&D1%"/"
dove D1 è la cella contentente il dato slug
(consiglio: considera di aggiungere anche il carattere wildcard*alla fine della formula: per capire perché vedi il secondo punto delle conclusioni di questo post) - estendo la formula a tutti i valori sottostanti
- copio-e-incollo i nuovi valori ottenuti, le URL, all’interno del box di aggiunta manuale URL del plugin.
Non resta che cliccare su “Add entries to 410 list” per completare l’operazione:
A meno che il tema WordPress installato non abbia una specifica pagina 410.php il plugin restituisce di default una semplice scritta:
Sorry, the page you requested has been permanently removed
Per una maggiore personalizzazione vale la pena creare una pagina specifica 410 da copiare nella cartella di default del tema installato, magari partendo dalla 404 (sempre presente su qualsiasi template).
Conclusioni
Prima di dichiarare conclusa la pratica ho controllato che:
- la Sitemap del sito fosse stata aggiornata e che presentasse solo i tag effettivamente utilizzati: ✔️OK
- tra gli errori 404 generati nei giorni successivi l’operazione non comparissero stranezze: ✔️OK
(ho notato un po’ di accessi falliti sui feed XML dei tag, sito.it/tag/feed/,ma dubito siano i crawler di Google… approfondirò sui log di Apache)
(aggiornamento: ovviamente era proprio Googlebot. 😄 Ho risolto aggiungendo il carattere jolly*alla fine delle URL[sito.it/tag/nometag/*])
Lezione appresa:
- non esagerare con i tag su WordPress, aggiungili se sono realmente utili e sforzati di utilizzarli per più articoli (evitando fare misere associazioni 1 a 1)
- quando una risorsa non è più utile (e non lo sarà mai più) – se non ha senso (o non puoi) reindirizzare il visitatore verso altre risorse – eliminala e fallo sapere a Google con un HTTP status 410:
Using the 410 response code will at least ensure that Google won’t ever go back to that page again and get to the more important pages on the site, helping overall crawlability. The 410 response code should be used when there isn’t another option and that the page cannot be redirected to a similar or corresponding page. So if you’re sure that a page no longer exists and will never exist again, using a 410 can be a good thing. [fonte: https://www.bluecorona.com/blog/410-error/]
Così Google non tornerà più sulla (vana) risorsa in questione e destinerà le sue energie altrove (dove c’è davvero ciccia).
Ciao Eugenio,
molto interessante per me il Tuo articolo sui tag in quanto mi trovo nelle stessa Tua situazione. Ti chiedo, se installo il plugin “410 for wordpress” e bonifico cioè attribuisco il 410 ai tag incriminati poi posso rimuovere il plugin tranquillamente o il plugin deve restare attivo ed installato vita natural durante? Cioè se dopo l’attribuzione del 410 rimuovo il plugin quelle pagine Tag resteranno eliminate definitivamente con lo lo status code 410 (Gone).
Ciao Vittorio,
scusami se ti rispondo con ritardo, ma ho letto solo ora il tuo commento.
Il plugin va lasciato per un po’, almeno fin quando quelle risorse non verranno “dimenticate” definitivamente da Google e altri.
A presto.
Ciao Eugenio, come menzioni alla fine dell’articolo, va bene anche un redirect anziché un 410, giusto?
Ciao Giulio,
se l’utente che visita la vecchia pagina può trovare le informazioni che cerca su una nuova risorsa… OK per il redirect 301!
Ciao,
sto effettuando anche io una pulizia in tal senso, avendo il tuo stesso problema (tag con 1 articolo al massimo).
Al momento ho impostato su “No Index” tutte le pagine tag, anche perchè ho notato dalla Search Console che tutte le pagine tag hanno ricevuto, nel complesso negli ultimi 3 mesi, non più di 20 click.
Pensi che sia comunque una soluzione appropriata, quella di inserire direttamente un No Index in tutte le pagine “Tag Archive”?
Grazie mille,
Luca
Ciao Luca,
scusa l’estremo ritardo nella risposta.
Sì, il no index ci può stare – comunica ai motori di non indicizzare quella risorsa.
Risorsa che però, si suppone, sia già indicizzata. Quindi comunque andrei anche di redirect.
Ciao, grazie per questo articolo davvero molto interessante. Trovo tutto utile nel caso si volesse ripulire qualcosa di già realizzato. Io ho tagliato la testa al toro evitando che i tag siano indicizzati sui motori di ricerca e devo dire che il posizionamento non ha subito variazioni anzi è migliorato per certi versi. Cosa ne pensi? faccio bene a chiedere a google di non indicizzare i tag dei miei articoli?
Ciao, scusa il ritardo nella risposta.
Beh, nel momento in cui effettivamente quel tipo di risorse non rispondono ad alcuna esigenza in SERP ci sta, eccome.
Quello che mi chiedo è: quelle pagine hanno senso, invece, per il tuo navigatore?
Qualche utente utilizzerà realmente quel tipo di paginazione?
Se la risposta è no… falle scomparire.