Crawling und Indexierung

Kann Google die Seite lesen? Die robots.txt sagt Crawlern, was sie dürfen. Ein falscher Eintrag sperrt CSS, Bilder oder ganze Bereiche. Ich prüfe sie für Google, Bing und die KI-Crawler von OpenAI, Anthropic und Perplexity, weil eine Sperre dort inzwischen genauso viel kostet.

Was steht im Index? In der Search Console sehe ich, welche Seiten Google kennt, welche es ausschließt und warum: noindex, Canonical auf eine andere Seite, Weiterleitung, Fehler, „gecrawlt, zurzeit nicht indexiert". Letzteres ist meist ein Inhaltsproblem, kein technisches, und ich sage das dann.

Sitemap. Eine XML-Sitemap listet die Seiten, die indexiert werden sollen, mit Änderungsdatum. Sie muss zur Seite passen: keine Weiterleitungen, keine Fehlerseiten, keine noindex-Seiten darin.

Canonicals. Wenn eine Seite unter mehreren Adressen erreichbar ist (mit und ohne Schrägstrich, mit Parametern, mit und ohne www), sagt der Canonical, welche zählt. Fehlt er oder zeigt er falsch, verteilt sich die Wertung auf Dubletten.

Weiterleitungen und Statuscodes. 301 für dauerhaft, keine Ketten, keine Schleifen, 404 für Seiten, die es nicht mehr gibt, 410 für bewusst entfernte. Fehlerseiten mit Statuscode 200 sind ein häufiger Fehler bei Baukästen.

JavaScript. Google rendert JavaScript, aber später und nicht immer vollständig. Inhalte, die nur per JavaScript erscheinen, sind ein Risiko. Ich prüfe, was im gerenderten HTML tatsächlich steht.

Ladezeit und Core Web Vitals

Google misst drei Werte bei echten Besuchern und nutzt sie als Rankingsignal:

  • LCP, die Ladezeit des größten sichtbaren Elements: bis 2,5 Sekunden.
  • INP, die Reaktionszeit auf eine Eingabe: bis 200 Millisekunden.
  • CLS, die Verschiebung des Layouts beim Laden: bis 0,1.

Gemessen wird am 75. Perzentil über 28 Tage, also nicht der Bestfall, sondern das, was drei Viertel der Besucher mindestens erleben. Ich messe im Labor mit Lighthouse und sehe die Felddaten aus Googles Bericht zur Nutzererfahrung, wenn die Seite genug Besucher hat.

Die üblichen Ursachen für schlechte Werte: zu große Bilder, Schriften von fremden Servern, Diashows und Videos im sichtbaren Bereich, Skripte von Drittanbietern, Page-Builder mit hundert Kilobyte CSS je Seite, Server ohne Cache. Die üblichen Maßnahmen: Bilder in WebP oder AVIF mit festen Maßen, Schriften selbst hosten, Skripte verzögern oder entfernen, Cache auf dem Server, kritisches CSS zuerst.

Mobil und Seitenerfahrung

Google bewertet die mobile Fassung. Ich prüfe Darstellung, Schriftgrößen, Klickflächen, Abstände, ob Inhalte auf dem Handy fehlen, die auf dem Desktop da sind, und ob Einblendungen den Inhalt verdecken. Dazu HTTPS ohne gemischte Inhalte, ein gültiges Zertifikat, das sich selbst erneuert, und Sicherheits-Header, die Browser und Google erwarten.

Strukturierte Daten

Strukturierte Daten sagen Google in maschinenlesbarer Form, was auf der Seite steht: Unternehmen, Anschrift, Leistungen, Pfad, Person, Artikel. Ich setze sie dort ein, wo sie passen, prüfe sie mit Googles Test und sage, wo sie nichts bringen. Google hat 2026 die Rich Results für FAQ-Markup abgeschafft, und Google selbst schreibt, dass strukturierte Daten hilfreich, aber nicht erforderlich sind. Sie ersetzen keinen Inhalt.

Logfiles und Crawl-Budget

Bei größeren Seiten sehe ich in den Server-Logfiles, welche Seiten Google tatsächlich abruft, wie oft und mit welchem Ergebnis. Daraus erkennt man Crawl-Fallen: endlose Parameter, Kalender, Filterkombinationen, die tausende nutzlose Adressen erzeugen. Für kleine Seiten ist das kein Thema, für Shops und Portale das erste.

Was Sie von mir bekommen

  • Eine technische Prüfung mit Befund je Punkt und Priorität.
  • Die Behebung, wenn Sie wollen, an Ihrer Seite und Ihrem Server, mit Sicherung vorher und Protokoll danach.
  • Messung vorher und nachher, Labor und Feld, dokumentiert.
  • Eine Dokumentation der Serverkonfiguration, damit der nächste, der daran arbeitet, weiß, was warum so eingestellt ist.

Beispiel aus der Praxis

Diese Seite. Sie ist als Beleg gebaut: eigene Schriften auf dem Server, keine Drittanbieter, Bilder mit festen Maßen, strukturierte Daten je Seite, Sitemap, Canonicals, KI-Crawler freigegeben. Die Messwerte stehen nach dem Prüfbericht auf der Startseite, mit dem, was nicht messbar war.

Ein zweites Beispiel: ein Freizeitbetrieb mit mehreren Domains, die alle auf dieselben Inhalte zeigten, teils mit alten Adressen, teils ohne Weiterleitung. Die Ordnung war technisch: eine Leitdomain, Weiterleitungen von allen anderen, Canonicals, eine Sitemap. Danach wusste Google, welche Adresse zählt. Der Name steht hier, sobald der Kunde zustimmt.

Fragen und Antworten

Reicht ein Cache-Plugin für die Ladezeit? Es hilft, aber es behebt nicht die Ursache. Wenn die Seite drei Megabyte Bilder lädt, ist sie mit Cache immer noch langsam.

Wie oft muss technisches SEO gemacht werden? Einmal gründlich, danach bei jeder größeren Änderung an der Seite und einmal im Jahr als Kontrolle. Die Search Console meldet dazwischen, wenn etwas kippt.

Kann ich die Core Web Vitals selbst messen? Ja, mit PageSpeed Insights von Google. Die Interpretation ist der schwierige Teil: Labor und Feld unterscheiden sich, und nicht jeder rote Wert ist wichtig.

Brauche ich einen eigenen Server? Nicht zwingend. Aber bei Shared-Hosting mit schlechter Antwortzeit hilft die beste Optimierung der Seite wenig. Ich sage Ihnen, ob der Server das Problem ist.

Was ist mit hreflang und Mehrsprachigkeit? Nur, wenn es mehrere Sprachen gibt. Dann gehört die Zuordnung der Sprachfassungen dazu, und sie ist fehleranfällig.

Nächster Schritt

Schicken Sie mir die Adresse Ihrer Seite. Die technische Grundprüfung ist in kurzer Zeit gemacht, und ich sage Ihnen, ob es ein Technikproblem ist oder ein anderes.