Eine Immobilien-Website generiert Hunderte, manchmal Tausende von URLs, die mit Anzeigen, Stadtteilseiten, Suchfiltern und der Paginierung verbunden sind. Die XML-Sitemap bestimmt, welche Seiten die Google-Roboter beim Crawlen priorisieren. Bei dieser Art von Website bedeutet es, die Kontrolle über diese Datei zu verlieren, dass Googlebot allein entscheidet, was er erkundet, mit einem direkten Risiko der Verdünnung des Crawl-Budgets auf wertlose Seiten.
Crawl-Budget und Immobilienanzeigen: das eigentliche technische Problem
Google weist jeder Website ein begrenztes Crawl-Volumen zu. Auf einem Immobilienportal sind die meisten URLs vergänglich: Ein verkauftes Objekt verschwindet innerhalb weniger Wochen aus dem Katalog, aber seine URL bleibt zugänglich, wenn nichts unternommen wird. Wenn die Sitemap weiterhin diese abgelaufenen Seiten referenziert, verstreut sich das Crawl auf tote Anzeigen, anstatt sich auf aktive Objekte zu konzentrieren.
Das Problem verschärft sich mit den Ergebnisseiten der Filter. Jede Kombination “3 Zimmer + Terrasse + Bordeaux” kann eine eigene URL generieren. Multiplizieren Sie dies mit der Anzahl der verfügbaren Kriterien, und Sie erhalten ein Volumen an facettierten Seiten, das die tatsächliche Anzahl der Anzeigen bei weitem übersteigt. Diese URLs blähen index künstlich auf, ohne einzigartigen Inhalt zu liefern.
Wir empfehlen, in die Sitemap nur drei Kategorien von Seiten aufzunehmen: die aktuellen Objektblätter, die Seiten für nachhaltige geografische Gebiete (Stadt, Stadtteil, Bezirk) und redaktionelle Inhalte. Alles andere, einschließlich abgelaufener Anzeigen, sollte ausgeschlossen und durch eine Weiterleitung oder einen HTTP-Code 410 behandelt werden.
Um diese Logik an einem konkreten Beispiel zu beobachten, zeigt die Sitemap von yakaimmo.fr die Struktur einer Datei, die auf die aktiven Inhalte eines Immobilienportals ausgerichtet ist.
Immobilien-Sitemap und Lebenszyklus der Objekte: die Datei mit dem Anzeigenfluss synchronisieren
Eine statische Sitemap ist mit einem dynamischen Immobilienkatalog unvereinbar. Die Objekte kommen und gehen ständig aus dem Bestand. Die Datei muss diesen Zustand in Echtzeit oder zumindest täglich widerspiegeln.
Das Tag <lastmod> spielt hier eine entscheidende Rolle. Wenn es nicht aktualisiert wird, wenn sich der Preis oder der Status einer Anzeige ändert, erkennt Google kein Signal der Frische. Auf einer Website, auf der täglich Dutzende von Blättern aktualisiert werden, bedeutet ein festes lastmod, dem Roboter zu sagen, dass sich nichts bewegt.
Konkret muss die Synchronisation zwischen dem Immobilien-CRM (oder dem Datenfluss des Netzwerks) und der Sitemap dieser Logik folgen:
- Ein veröffentlichtes Objekt fügt automatisch seine URL zur Sitemap mit dem aktuellen Datum als lastmod hinzu.
- Ein verkauftes, zurückgezogenes oder abgelaufenes Objekt entfernt seine URL innerhalb von 24 Stunden aus der Sitemap und gibt einen HTTP-Code 410 (Gone) oder eine 301-Weiterleitung zur Seite des betreffenden Gebiets zurück.
- Eine Preis- oder Beschreibungsänderung aktualisiert das lastmod, ohne die URL selbst zu berühren.
Diese Mechanik verhindert, dass widersprüchliche Signale an Googlebot gesendet werden: Eine URL, die in der Sitemap vorhanden ist, aber einen 404 zurückgibt, erzeugt Abdeckungsfehler in der Search Console und verringert das allgemeine Vertrauen in die Domain.
Kreuzdiagnose: Sitemap, Server-Logs und Crawl Stats
Eine saubere Sitemap einzureichen reicht nicht aus. Es muss auch überprüft werden, ob Google tatsächlich die Seiten crawlt, die Sie ihm vorlegen. Hier wird der Abgleich zwischen der Sitemap und den Server-Logs zu einem eigenständigen technischen Diagnoseschritt.
Der Bericht über Crawl Stats in der Search Console zeigt die Anzahl der täglichen Anfragen und die durchschnittliche Antwortzeit an. Parallel dazu zeigt die Analyse der Server-Logs, welche URLs Googlebot tatsächlich besucht. Auf einer umfangreichen Immobilien-Website kommt es häufig vor, dass der Roboter einen erheblichen Teil seines Budgets auf Paginierungsseiten oder Filter-URLs verwendet, während er frisch veröffentlichte Objektblätter ignoriert.
Die Diagnose besteht darin, drei Listen zu vergleichen:
- Die URLs, die in der Sitemap vorhanden sind (was Sie Google bitten, zu erkunden).
- Die URLs, die tatsächlich von Googlebot gecrawlt werden (was die Logs zeigen).
- Die indexierten URLs (was der Abdeckungsbericht bestätigt).
Wenn die Diskrepanz zwischen der Sitemap und den gecrawlten URLs einen angemessenen Schwellenwert überschreitet, deutet dies auf ein Architekturproblem hin: unzureichende interne Links zu den neuen Blättern, zu hohe Server-Antwortzeiten oder das Vorhandensein von störenden URLs, die das Crawl anziehen. Eine gut konstruierte Sitemap kompensiert kein fehlerhaftes internes Linking, aber sie ermöglicht eine präzise Messung, wo die Verluste auftreten.
JavaScript-Rendering und Sitemap: eine spezifische Herausforderung für Immobilienportale
Viele Immobilienplattformen basieren auf JavaScript-Frameworks (React, Vue, Angular), um die Objektblätter und Suchergebnisse anzuzeigen. Google kann JavaScript rendern, jedoch mit einer Verzögerung und Ressourcenbeschränkungen. Die Sitemap löst dieses Problem nicht: Das Einreichen einer nur in JS gerenderten URL garantiert nicht deren Indexierung.
Wenn der Hauptinhalt eines Blattes (Adresse, Preis, Fläche, Fotos) vollständig vom Client-Seiten-Rendering abhängt, kann der Roboter die im Sitemap referenzierte URL crawlen und beim ersten Besuch nur eine leere Hülle finden. Die Seite wird für ein zweites Rendering in die Warteschlange gestellt, ohne Garantie für die Dauer.
Wir beobachten, dass Immobilien-Websites, die ein Server-Rendering (SSR) für die kritischen Elemente des Blattes und eine aktualisierte Sitemap kombinieren, eine deutlich höhere Indexabdeckung erzielen als diejenigen, die ausschließlich auf die Sitemap setzen, um ein vollständiges JS-Rendering auszugleichen. Die Sitemap zeigt, wo man hingehen soll, ersetzt jedoch nicht die technische Qualität dessen, was der Roboter bei seiner Ankunft findet.
Eine leistungsfähige Immobilien-Sitemap basiert auf drei Säulen: der Synchronisation mit dem Anzeigenfluss, der strengen Ausschluss von wertlosen URLs und der regelmäßigen Überprüfung durch den Abgleich von Logs/Crawl Stats. Ohne diese Wartungsarbeit bleibt die Datei ein passives Inventar, das weder die Indexierungsgeschwindigkeit noch die Sichtbarkeit der zum Verkauf stehenden Objekte verbessert.