Un sito immobiliare genera centinaia, a volte migliaia di URL legate agli annunci, alle pagine dei quartieri, ai filtri di ricerca e alla paginazione. Il sitemap XML determina quali pagine i robot di Google daranno priorità durante il crawl. Su questo tipo di sito, non padroneggiare questo file equivale a lasciare che Googlebot decida da solo cosa esplorare, con un rischio diretto di diluizione del budget di crawl su pagine senza valore.
Budget di crawl e annunci immobiliari: il vero problema tecnico
Google assegna a ogni sito un volume di crawl limitato. Su un portale immobiliare, la maggior parte delle URL sono effimere: un bene venduto scompare dal catalogo in poche settimane, ma la sua URL rimane accessibile se non si interviene. Se il sitemap continua a fare riferimento a queste pagine scadute, il crawl si disperde su annunci morti invece di concentrarsi sui beni attivi.
Il problema si aggrava con le pagine dei risultati dei filtri. Ogni combinazione “3 stanze + terrazzo + Bordeaux” può generare un’URL distinta. Moltiplicate per il numero di criteri disponibili e otterrete un volume di pagine facettate che supera di gran lunga il numero di annunci reali. Queste URL gonfiano artificialmente l’indice senza apportare contenuti unici.
Raccomandiamo di includere nel sitemap solo tre categorie di pagine: le schede dei beni in fase di commercializzazione, le pagine delle aree geografiche durature (città, quartiere, arrondissement) e i contenuti editoriali. Tutto il resto, comprese le annunci scaduti, deve essere escluso e trattato tramite una redirezione o un codice 410.
Per osservare questa logica applicata a un caso concreto, il sitemap di yakaimmo.fr illustra la strutturazione di un file orientato verso i contenuti attivi di un portale immobiliare.
Sitemap immobiliare e ciclo di vita dei beni: sincronizzare il file con il flusso di annunci
Un sitemap statico è incompatibile con un catalogo immobiliare dinamico. I beni entrano ed escono dallo stock continuamente. Il file deve riflettere questo stato in tempo reale, o almeno quotidianamente.
Il tag <lastmod> assume qui tutto il suo peso. Se non viene aggiornato quando un annuncio cambia prezzo o stato, Google non percepisce alcun segnale di freschezza. Su un sito dove decine di schede evolvono ogni giorno, un lastmod fisso equivale a dire al robot che nulla si muove.
Concretamente, la sincronizzazione tra il CRM immobiliare (o il flusso di dati della rete) e il sitemap deve seguire questa logica:
- Un bene pubblicato aggiunge automaticamente la sua URL al sitemap con la data del giorno in lastmod.
- Un bene venduto, ritirato o scaduto rimuove la sua URL dal sitemap entro 24 ore e restituisce un codice HTTP 410 (Gone) o una redirezione 301 verso la pagina dell’area interessata.
- Una modifica di prezzo o di descrizione aggiorna il lastmod senza toccare l’URL stessa.
Questa meccanica evita di inviare segnali contraddittori a Googlebot: un’URL presente nel sitemap ma che restituisce un 404 genera errori di copertura nella Search Console e degrada la fiducia globale del dominio.
Diagnosi incrociata: sitemap, log del server e Crawl Stats
Inviare un sitemap pulito non è sufficiente. È necessario verificare che Google crawli effettivamente le pagine che gli si sottopongono. È qui che l’incrocio tra il sitemap e i log del server diventa una fase di diagnosi tecnica a tutti gli effetti.
Il rapporto Crawl Stats della Search Console indica il numero di richieste quotidiane e il tempo di risposta medio. In parallelo, l’analisi dei log del server rivela quali URL Googlebot visita realmente. Su un sito immobiliare voluminoso, capita frequentemente che il robot spenda una parte significativa del suo budget su pagine di paginazione o URL di filtri, ignorando nel contempo schede di beni appena pubblicate.
La diagnosi consiste nel confrontare tre liste:
- Le URL presenti nel sitemap (quello che chiedete a Google di esplorare).
- Le URL effettivamente crawlate da Googlebot (quello che i log mostrano).
- Le URL indicizzate (quello che il rapporto di copertura conferma).
Se la differenza tra il sitemap e le URL crawlate supera una soglia ragionevole, ciò segnala un problema di architettura: link interni insufficienti verso le nuove schede, tempo di risposta del server troppo elevato o presenza di URL parassite che catturano il crawl. Un sitemap ben costruito non compensa una rete interna difettosa, ma consente di misurare precisamente dove si trova la dispersione.
Rendering JavaScript e sitemap: una costrizione specifica per i portali immobiliari
Molte piattaforme immobiliari si basano su framework JavaScript (React, Vue, Angular) per visualizzare le schede dei beni e i risultati di ricerca. Google può rendere il JavaScript, ma con un ritardo e limiti di risorse. Il sitemap non risolve questo problema: inviare un’URL renderizzata solo in JS non garantisce la sua indicizzazione.
Se il contenuto principale di una scheda (indirizzo, prezzo, superficie, foto) dipende interamente dal rendering lato client, il robot può crawlare l’URL riferita nel sitemap e trovarvi solo un guscio vuoto al primo passaggio. La pagina sarà messa in coda per un secondo rendering, senza garanzia di tempistiche.
Osserviamo che i siti immobiliari che combinano un rendering server (SSR) per gli elementi critici della scheda e un sitemap aggiornato ottengono una copertura di indicizzazione nettamente superiore a quelli che puntano esclusivamente sul sitemap per compensare un rendering full-JS. Il sitemap segnala dove andare, ma non sostituisce la qualità tecnica di ciò che il robot trova all’arrivo.
Un sitemap immobiliare performante si basa su tre pilastri: la sincronizzazione con il flusso di annunci, l’esclusione rigorosa delle URL senza valore e la verifica regolare tramite incrocio log/Crawl Stats. Senza questo lavoro di manutenzione, il file rimane un inventario passivo che non migliora né la velocità di indicizzazione né la visibilità dei beni in vendita.