Yandex ha scansionato il mio blog senza /en. I redirect 308 hanno evitato i 404

Ho pubblicato un aggiornamento della sitemap con circa 3.000 nuove pagine sotto /en/blog/.... Poco dopo, Yandex Webmaster ha mostrato un pattern inatteso: Yandex provava a scansionare i percorsi corrispondenti sotto /blog/..., senza il prefisso /en.

Se quelle URL avessero restituito semplicemente 404, avrei potuto ritrovarmi con migliaia di tentativi di crawl inutili verso percorsi inesistenti. Per fortuna avevo già configurato redirect 308 permanenti dalle route senza prefisso linguistico alle vere URL inglesi.

Quella piccola difesa nel routing si è rivelata molto più utile di quanto pensassi.

Quello che ho realmente osservato

1. Ho pubblicato una sitemap con circa 3.000 nuove pagine nella struttura /en/blog/....
2. Subito dopo Yandex Webmaster ha mostrato tentativi di crawl verso le corrispondenti URL /blog/....
3. Quei percorsi alternativi erano già coperti dai miei 308.
4. Invece di finire in 404, le richieste venivano inviate alle URL corrette /en/blog/....

C’è però una correzione importante rispetto a come avevo raccontato inizialmente l’episodio: non posso dimostrare che Yandex abbia «interpretato male la sitemap». Ho osservato quei percorsi inattesi dopo l’aggiornamento, ma la sequenza temporale non dimostra la causa interna. Un motore di ricerca può scoprire URL attraverso più segnali e fonti storiche. Senza prove ulteriori, posso dire soltanto che Yandex ha scansionato percorsi che non mi aspettavo.

La distinzione conta: una richiesta strana del crawler è un dato osservato; spiegare esattamente perché abbia scelto quell’URL è un’affermazione diversa.

Perché i redirect 308 sono stati utili

La mia logica trattava il percorso corto come alias permanente dell’URL localizzata:

/blog/example-post  -> 308 ->  /en/blog/example-post

Così il crawler, pur entrando da un URL inatteso, raggiungeva comunque la pagina che volevo servire.

308 Permanent Redirect è un redirect HTTP permanente che conserva metodo e body della richiesta. Per i normali GET di un crawler, la conservazione del metodo di solito non è la parte interessante; qui era più importante il fatto che il redirect fosse esplicitamente permanente. La documentazione attuale di Yandex Webmaster classifica sia 301 sia 308 come redirect permanenti.

Documentazione ufficiale di Yandex Webmaster sui redirect.

Questo non significa che 308 sia automaticamente migliore di 301 per la SEO. Nel mio caso i 308 erano già presenti e facevano esattamente ciò che mi serviva: l’URL imprevisto non diventava un vicolo cieco.

Il redirect è una rete di sicurezza, non la correzione della sitemap

I redirect hanno contenuto il problema, ma non rendono desiderabile il crawl superfluo. Ogni redirect aggiunge una richiesta e un hop. Una regola troppo ampia può anche nascondere errori nella generazione degli URL se smetti di cercarne la fonte.

Se la sitemap stessa contiene URL obsolete o che redirigono, la soluzione corretta è correggere la sitemap e puntare agli URL finali. I redirect dovrebbero proteggere percorsi vecchi, alternativi o scoperti per errore; non giustificare dati URL imprecisi.

Nel mio caso la sitemap conteneva già /en/blog/.... I redirect rendevano semplicemente il sito più tollerante quando un crawler arrivava da /blog/....

Cosa controllerei oggi

1. Aprire la sitemap realmente deployata. Non fidarsi solo del generatore: controllare il file finale e alcune URL reali.
2. Verificare le risposte finali. Gli URL destinati all’indicizzazione dovrebbero arrivare direttamente alla pagina corretta, senza catene evitabili.
3. Testare percorsi alternativi prevedibili. Se un vecchio URL ha una destinazione permanente, il mapping deve essere esplicito e uno-a-uno.
4. Evitare catene. A -> B -> C è più difficile da controllare di A -> C.
5. Confrontare i report del crawler con dati server-side quando possibile. I Webmaster tool sono utili, ma non sempre dicono da dove sia stato scoperto un URL.
6. Non dedurre il ranking dal crawl. Crawling, indicizzazione, ranking e traffico sono fasi diverse.

curl -I https://example.com/blog/example-post

HTTP/2 308
location: https://example.com/en/blog/example-post

L’esempio è illustrativo: il punto è verificare status e destinazione esatti, invece di dare per scontato che la regola funzioni.

Cosa posso concludere e cosa no

Posso confermare che i 308 già configurati hanno impedito alle richieste inattese verso /blog/... di terminare in 404 e le hanno inviate agli URL previsti.

Non posso confermare che la causa fosse il parser della sitemap di Yandex. Non ho neppure misurato un aumento di ranking, un miglioramento dell’indicizzazione o una quantità precisa di traffico «salvato». Sarebbe andare oltre le prove disponibili.

La lezione che mi è rimasta è più stretta e più utile: l’architettura degli URL dovrebbe tollerare errori prevedibili ai confini del sistema. Una sitemap pulita resta la prima linea di difesa. Uno strato preciso di redirect permanenti è la seconda.

Con entrambi, un percorso inatteso del crawler ha molte meno probabilità di trasformarsi in migliaia di URL morte.