Stiamo osservando un numero elevato di URL di permalink dei topic e di paginazione che finiscono nella sezione “Crawled - currently not indexed” (Ripercorsi - attualmente non indicizzati) di Google Search Console (~35k URL su un forum importato di circa 20 anni, versione discourse v2026.9.0-latest, self-hosted).
Cosa abbiamo scoperto:
Discourse fornisce link di paginazione ?page=N ai crawler per i topic lunghi (poiché l’interfaccia reale utilizza lo scroll infinito). Quando un client con supporto JS (incluso il renderer di Googlebot) carica uno di questi URL ?page=N, Discourse esegue un redirect lato client verso /t/slug//<post_number>.
Riproduzione:
- Recupera un URL di topic in modo “a freddo”, con qualsiasi suffisso di numero di post o ?page=:
GET /t///14 →
GET /t// → stesso canonical
GET /t///1 → stesso canonical
GET /t//?page=127 → (auto-riferente, NON normalizzato) - Carica il sito normalmente (JS attivo) e naviga, tramite il router di Ember, verso un URL che include un suffisso di numero di post (ad esempio, facendo clic su un link “vai al primo post non letto” dai Topic Suggeriti). Una volta completata la transizione SPA, document.querySelector(‘link[rel=canonical]’).href corrisponde all’URL del numero di post corrente — non punta al topic di base.
Questo contraddice l’intento di progettazione dichiarato da Discourse stesso. In questo thread del 2015, @sam era esplicito:
▎ Topic: il canonical dovrebbe puntare al topic di base per evitare che le pagine di singoli post appaiano come risultati di ricerca discreti.
▎ Pagine di categoria/elenchi: canonical rimosso completamente, poiché gli elenchi paginati non sono duplicati secondo le linee guida di Google stesso.
Ciò che stiamo osservando oggi viola questo in due modi:
- Un topic con ?page=N (paginazione del crawler) contiene l’URL paginato nell’HTML grezzo del server, invece del topic di base — anche se i topic (a differenza degli elenchi di categoria) erano esplicitamente destinati a convergere sempre sull’URL di base.
- Dopo il redirect lato client da ?page=N a /t/slug/id/<post_number>, il canonical nel DOM renderizzato rimane su quell’URL con numero di post invece di resettarsi sul topic di base.
Entrambi sembrano essere regressioni rispetto all’obiettivo di progettazione del 2015, non un comportamento intenzionale attuale.
Perché questo è importante per l’indicizzazione: l’algoritmo di indicizzazione di Google si affida al DOM renderizzato per il segnale canonical. Qualsiasi URL con suffisso di numero di post/pagina a cui Google arriva direttamente — tramite la funzione “condividi link al post” (ampiamente utilizzata sul nostro forum via WhatsApp/Discord), tramite vecchi backlink esterni (stiamo mappando i permalink legacy vBulletin ?p= su URL con numero di post), o tramite il crawler stesso — dichiara il proprio canonical invece di consolidarsi nel topic di base. In Search Console questo si manifesta come migliaia di URL quasi duplicati bloccati in “crawled - not indexed”.
Esempi di URL interessati dal nostro report GSC (tutti ultimi ripercorsi a inizio settembre 2026):
/t/tengo-que-pasar-la-itv/21100/10
/t/new-honda-nsx-proyect/4910/69
/t/hacer-tubo-recto-sin-silencioso-del-catalizador-hacia-atras/25579/25
/t/kedada-japo-en-cataluna-2014/28148/75
/t/el-diario-de-patricio-de-la-plana/13286?p
Domanda per il team: dato che si tratta di un periodo superiore a 10 anni, qualcosa è cambiato da allora che rende intenzionale il canonical auto-riferente su questi URL? Oppure vale la pena riesaminare la questione come una regressione? Sono felice di fornire file HAR / ulteriori esempi di riproduzione se utili.