Indexbereinigung – Frühjahrsputz für den Google Index

29.09.2015

Eine gründliche OnPage-Optimierung beginnt in der Regel mit einer Indexbereinigung. Dies ist wichtig, da wir Google nur diejenigen Unterseiten für den Index anbieten möchten, die für den Nutzer ein relevantes und befriedigendes Ergebnis seiner Suchanfrage darstellen könnten. Typische nicht (unbedingt) sinnvolle Inhalte sind u.a. interner Duplicate Content (z. B. Seiten mit URL-Parametern wie Print-Versionen von Artikeln) und externer (identische Inhalte auf mehreren eigenen Domains), Pagination, Fehlerseiten oder Non-HMTL-Dateitypen, auf die wir später zu sprechen kommen. Aber auch sicherheitsrelevante Inhalten gehören natürlich nicht in den Index.

Gleichzeitig optimieren wir durch die Indexbereinigung die individuellen Ressourcen, die Google jeder Domain für ein Crawling zur Verfügung stellt – das sogenannte Crawling-Budget. Denn jedes Crawling verbraucht bei Google Ressourcen, z. B. Strom und damit Geld. Durch eine gezielte Steuerung der Indexierung können wir Google deutlich machen, welche Unterseiten für uns wichtig sind. Diese können dann häufiger gecrawlt werden und erhalten eine höhere Relevanz.

Wie man Google die relevanten eigenen Unterseiten deutlich macht, ist relativ einfach. So helfen zum Beispiel eine flache Seitenarchitektur (siehe Artikel von Moz) oder das übermitteln einer XML-Sitemap der Suchmaschine die wichtigen URLs der eigenen Domain klarzumachen.

Identifizieren von Müll im Index – Abfragen mit dem Suchoperator “site:”:

Doch wie identifizieren wir diejenigen Unterseiten, die schon im Index sind und dort nicht sein sollten? Am einfachsten geht dies über eine Suchabfrage mit dem Operator site:, z. B. site:xovi.de. Hiermit bekommen wir die Anzahl der von Google indexierten Unterseiten unserer Domain und die einzelnen URLs inklusive ihrer Suchergebnissnippets angezeigt. Vorsicht ist jedoch geboten: Die Anzeige der Anzahl gefundener Seiten wird ab einer bestimmten Größe hochskaliert und ist nicht zu 100% exakt.

Typische Abfragen für eine Indexbereinigung sind:

  • Alle URLs der gesamten Domain: site:domain.de
  • Alle URLs der Subdomain www: site:www.domain.de
  • Alle URLs außer der der Subdomain www: site:domain.de -site:www.domain.de
  • Alle URLs der Domain im Ordners /test/: site:domain.de/test/
  • Alle URLs der Domain mit Endung .html: site:domain.de filetype:html
  • Alle URLs der Domain mit “hallo welt” im Title: site:domain.de intitle:“hallo welt
  • Alle URLs der Domain mit “hallo welt” im Text: site:domain.de intext:“hallo welt

Das Schöne bei den angezeigten Ergebnissen ist, dass Google grob nach Relevanz der Unterseiten sortiert – wichtige URLs werden auf den ersten Seiten angezeigt, nicht relevante Seiten bzw. Index-Müll finden sich auf den letzten Seiten der Paginierung. Um schnell nach dort hinten zu gelangen hilft ein Trick: Einfach den Parameter &start=990 ans Ende der URL der Suchanfrage setzen, z. B. https://www.google.de/search?q=site%3Adomain.de&start=990.

Bei großen Websites empfiehlt es sich die Abfragen aufeinander aufzubauen bzw. auf Teilbereiche der Seite zu beschränken, da Google nicht alle URLs auch wirklich als Suchergebnis anzeigt. Ein typischer Ablauf, um alle Subdomains der eigenen Website herauszufinden wäre:

  1. Abfrage der URLs ohne die bekannte www-Subdomain: site:domain.de -site:www.domain.de.
  2. Verfeinern der Suchanfrage aus 1. mit allen Subdomains die man im ersten Schritt angezeigt bekommt, z. B. site:domain.de -site:www.domain.de -site:m.domain.de -site:stage.domain.de -site:test.domain.de.
  3. Wiederholung von Schritt 2 bis die Anzeige der indexierten Seite gleich null ist. Dann hat man alle indexierten Subdomains der Domain gefunden und kann sich einzeln um diese kümmern.

Befinden sich auf einer Subdomain sehr viele URLs, wie typischerweise bei www., dann empfiehlt es sich ordnerweise vorzugehen:

  1. Abfrage der URLs der www-Subdomain: site:www.domain.de
  2. Spezifizieren der Suchanfrage aus 1. durch Beschränkung auf einen der Ordner, die jetzt sichtbar viele URLs beinhalten, z. B. site:www.domain.de/artikel/.
  3. Enden jetzt z . B. alle Artikel mit .html und ist man sich sicher, dass diese in den Index gehören, so kann es sich lohnen diese auszuschließen um Dokumente in diesem Ordner aufzudecken, die man Google nicht anbieten möchte: site:www.domain.de/artikel/ -filetype:html.
  4. Verfeinern der genannten Suchanfragen durch wiederholtes Ausschließen von entdeckten sinnvollen und nicht sinnvollen Unternordnern und Dokumenten.

Durch diese Methode nähert man sich iterativ den überflüssigen URLs und Dokumenten im Index und kann diese später deindexieren. Weiterer Vorteil: Gleichzeitig kann man für die wichtigen Unterseiten, die im Index bleiben sollen auch die Angaben im Snippet überprüfen und dabei so manche Kriterien prüfen: Stimmt die Länge von Title und Description, ist ein Call-to-Action vorhanden, gibt es überall sprechende und selbsterklärende URLs und werden die ausgezeichneten strukturierten Daten als Rich-Snippets angezeigt?

Wie bekomme ich die überflüssigen Inhalte aus dem Google Index?

Um URLs und Dateien ein für alle Mal aus dem Webindex zu entfernen, gibt es mehrere Methoden:

  • Meta-Tag noindex: Durch die Angabe <meta name="robots" content="noindex" /> im Header eines HTML-Dokumentes wird die Seite gecrawlt, aber nicht indexiert. Zudem wird weiterhin den internen und externen Verlinkungen auf der Seite gefolgt (gleichbedeutend mit <meta name="robots" content="noindex, follow" />).
  • Canonical-Tag: Mit Hilfe der Angabe eines <link>-Elements mit dem Attribut rel=“canonical“ im Header-Bereich können Unterseiten mit gleichen oder fast gleichen Inhalten eine kanonische URL an Google übergeben, die dann indexiert werden soll, während die andere ignoriert wird.
  • 301-Redirect: Der 301-Statuscode besagt, dass eine Seite dauerhaft an einen neuen Speicherort verschoben wurde. Über einen 301- Redirect in der .htaccess-Datei kann eine oder mehrere URLs auf eine andere weitergeleitet werden. So wird nur das Weiterleitungsziel selbst indexiert. Der Vorteil bei dieser Methode ist, dass eventuell vorhandene externe Backlinks inklusive ihrer Linkpower auf die neue URL übertragen werden
  • HTTP-Statuscode 410 (bzw. 404): Der Statuscode 410 bedeutet “gone”. Das besagt, dass diese URL dauerhaft entfernt wurde. Ein 404 hingegen signalisiert, dass die Zieldatei lediglich “nicht gefunden” wurde (“not found”) bzw. ursprünglich nie existierte. Daher ist der 410 faktisch der korrekte Statuscode um Inhalte aus dem Index zu entfernen, die nicht mehr existieren. Effektiv funktionieren aber beide Statuscodes.
  • Google Search Console: Im Menü unter “Google-Index” befindet sich der Punkt “URLs entfernen”. Hier lassen sich einzelne URLs manuell eingeben und damit schnell und sauber aus dem Index entfernen. Für das Entfernen größerer Mengen von Unterseiten ist diese Methode jedoch nicht praktikabel.
  • robots.txt: Die robots.txt-Datei steuert das Crawling, nicht die Indexierung! Das wird auch heute noch häufig verwechselt, daher hier der nochmalige Hinweis: Seiten die über diese Datei vom Crawling ausgeschlossen sind können trotzdem im Index landen. Daher ist die robots.txt für eine Indexbereinigung nicht geeignet, in manchen Fällen sogar hinderlich.

Indexsteuerung für Nicht-HTML-Dokumente

Es gibt auch Nicht-HTML-Dateitypen, die ihren Weg in den Index der Suchmaschine finden können. Folgende Dateien sind generell von Google indexierbar und können über die oben genannte filetype-Abfrage abgerufen werden (Quelle):

  • Adobe Flash (.swf)
  • Adobe Portable Document Format (.pdf)
  • Adobe PostScript (.ps)
  • Autodesk Design Web Format (.dwf)
  • Google Earth (.kml, .kmz)
  • GPS Exchange Format (.gpx)
  • Hancom Hanword (.hwp)
  • HTML (.htm, .html oder andere Dateierweiterungen)
  • Microsoft Excel (.xls, .xlsx)
  • Microsoft PowerPoint (.ppt, .pptx)
  • Microsoft Word (.doc, .docx)
  • OpenOffice-Präsentation (.odp)
  • OpenOffice-Tabelle (.ods)
  • OpenOffice-Text (.odt)
  • Rich Text Format (.rtf, .wri)
  • Skalierbare Vektorgrafiken (.svg)
  • TeX/LaTeX (.tex)
  • Text (.txt, .text oder andere Dateierweiterungen) einschließlich Quellcode in gängigen Programmiersprachen:
  • Basic-Quellcode (.bas)
  • C/C++ Quellcode (.c, .cc, .cpp, .cxx, .h, .hpp)
  • C#-Quellcode (.cs)
  • Java-Quellcode (.java)
  • Perl-Quellcode (.pl)
  • Python-Quellcode (.py)
  • Wireless Markup Language (.wml, .wap)
  • XML (.xml)

Falls man diese Dateitypen auf der eigenen Website zum Download anbietet oder anderweitig verwendet, empfiehlt es sich diese trotzdem aus dem Index zu entfernen. PDF-Dateien beispielsweise können von Google sehr gut ausgelesen werden (selbst Links aus dem PDF werden gewertet) und haben gute Rankingchancen. Das Problem: Wer über Google auf einem PDF landet hat keine Seitennavigation und kann daher nicht auf der Website weiterklicken. Für weitere Pageviews oder Klicks auf geschaltete Anzeigen sorgt dieser User dann auf jeden Fall nicht mehr. Die Empfehlung lautet daher für jedes Dokument dieser Art eine Landingpage zu bauen, die den Inhalt der Datei beschreibt bzw. anteasert und das PDF zum Download anbietet. Die Datei selbst sollte aber auf noindex stehen. Dieses lässt sich über das X-Robots-Tag bewerkstelligen, da hier natürlich kein HTML-Header zur Verfügung steht. Jede Anweisung (z. B. “noindex”), die in einem Robots-Meta-Tag verwendet werden kann, kann auch als X-Robots-Tag im HTTP-Header angegeben werden. Diese müssen in die .htaccess (bzw. die httpd.conf) des Servers eingetragen werden. Dazu gibt es eine offizielle Anleitung von Google.

Erfolgskontrolle – Hat’s geklappt?

Der Erfolg der getätigten Maßnahmen zur Indexbereinigung lässt sich in der Search Console (ehemals Google Webmaster-Tools) einfach überwachen: Im Menü unter “Google Index” findet man den Punkt “Indexierungsstatus”, dort wird angezeigt, wie viele Unterseiten der eigenen Website indexiert sind. In der erweiterten Ansicht lassen sich sogar die Anzahl der von der Robots.txt-Datei blockierten und die bereits aufgrund eines Antrags auf Entfernung aus dem Index gelöschten Unterseiten überwachen. So hat man stets die volle Kontrolle über den eigenen Stand der Indexierung.

Diesen Beitrag teilen