Noi misuriamo il file realmente servito in production. Google documenta un limite di 500 KiB; il contenuto oltre quel limite può essere ignorato.
Manteniamo UTF-8 coerente
Evitiamo codifica legacy e byte invalidi. Per path non ASCII controlliamo anche l’escaping URL.
Riduciamo la duplicazione
I file grandi contengono spesso URL elencate una a una, commenti generated o gruppi duplicati. Pattern di percorso stabili sono più facili da mantenere.
Validiamo dopo ogni semplificazione
Una wildcard più corta può diventare troppo ampia. Usiamo il validator e il tester dopo modifiche strutturali.
Controlliamo la consegna HTTP
CDN, redirect o generazione dinamica possono servire contenuto diverso. Il checker conferma status e file production.
Il limite di 500 KiB è operativo
Google elabora robots.txt fino a circa 500 KiB e può ignorare il contenuto successivo. Lasciamo quindi un margine ampio invece di puntare al limite. Una regola importante collocata troppo in fondo può esistere nel repository ma non essere processata dal crawler.
I problemi di encoding sembrano problemi di matching
Controlliamo i byte UTF-8 realmente serviti, non solo ciò che mostra l’editor: BOM, caratteri sostitutivi, path non ASCII, maiuscole/minuscole e forme percent-encoded. Verifichiamo anche che il server restituisca testo e non una pagina HTML di errore mascherata.
Quando il file cresce troppo, cerchiamo gruppi duplicati, regole per singolo URL e liste di bot enormi. Un set più piccolo e comprensibile è più facile da verificare e meno esposto ai limiti.
Manteniamo margine operativo
Non basta restare appena sotto 500 KiB. Lasciamo spazio per commenti, nuovi gruppi crawler e cambi futuri della piattaforma, quindi controlliamo nuovamente la dimensione del file realmente servito dopo il deploy. Se la crescita dipende da regole generate automaticamente, preferiamo correggere il generatore invece di accettare un file sempre più vicino al limite.
