Ja, die Seitengeschwindigkeit ist ein best\u00e4tigter Rankingfaktor f\u00fcr Google, sowohl im Desktop- als auch im mobilen Index. Seit dem Page Experience Update 2021 ist sie ein direktes Signal im Ranking-System. Allerdings ist sie kein alleiniger Dominator: Ein langsamerer Satz einer hochrelevanten Seite kann noch ranken, w\u00e4hrend eine uninformative Seite selbst bei Blitzgeschwindigkeit unsichtbar bleibt.<\/p>\n
Das ist die pr\u00e4zise Antwort, aber die Praxis ist differenzierter. Viele Gesch\u00e4ftsinhaber und Vermarkter, mit denen wir arbeiten, glauben, dass das Erreichen einer perfekten 100 im PageSpeed Insights automatisch auf Platz 1 katapultiert. Das ist falsch. Die Seitengeschwindigkeit wirkt als Schwellenwert und als Verst\u00e4rker. Unterhalb einer bestimmten Grenze bestraft sie. Oberhalb dieser Grenze verbessert sie die Nutzererfahrung und damit indirekt die Interaktionssignale, die Suchmaschinen messen. Der wahre Hebel liegt darin, zu verstehen, wo die Verlangsamung auftritt und ob sie Ihre Inhalte daran hindert, gecrawlt und indexiert zu werden.<\/p>\n
Google selbst hat best\u00e4tigt, dass die Seitengeschwindigkeit ein Ranking-Signal ist, aber es ist nur eines von \u00fcber 200 Signalen. In der Praxis sehen wir, dass die Seitengeschwindigkeit als differenzierender Faktor<\/strong> wirkt: Bei ansonsten gleichwertigen Inhalten mit \u00e4hnlicher Relevanz und Autorit\u00e4t entscheidet die schnellere Seite. Bei grossen inhaltlichen oder autoritativen Unterschieden gewinnt jedoch meist die langsamere, aber bessere Seite.<\/p>\n Ein entscheidender Punkt: Die Geschwindigkeit beeinflusst massgeblich das Crawling-Budget. Wenn Ihre Seite langsam l\u00e4dt, reduziert Googlebot die Crawling-Rate. Das bedeutet, neue oder aktualisierte Inhalte werden m\u00f6glicherweise nicht erkannt, selbst wenn sie eigentlich f\u00fcr die Rankings wichtig w\u00e4ren. Wir haben F\u00e4lle gesehen, wo ein Kunden-Blog mit herausragenden Inhalten monatelang nicht indexiert wurde, weil die Server-Antwortzeit \u00fcber 3 Sekunden lag. Nach der Optimierung auf unter 1 Sekunde war der Inhalt innerhalb von 48 Stunden indexiert.<\/p>\n Sie ist beides. Google hat klargestellt, dass Geschwindigkeit ein direktes Signal in seinen Algorithmen ist, das Teil des Page Experience-Faktors ist. Gleichzeitig wirkt sie indirekt \u00fcber die Nutzererfahrung. Eine langsame Seite erh\u00f6ht die Absprungrate drastisch. Wenn ein Nutzer die Seite verl\u00e4sst, weil sie nicht l\u00e4dt, sendet das negatives Feedback an Google. Das heisst: Der direkte Effekt ist messbar, aber der indirekte Effekt \u00fcber Metriken wie die Verweildauer oder die Klickrate ist in der Praxis oft noch gewichtiger.<\/p>\n Praxistipp aus unserer Agenturarbeit:<\/strong> Wir haben bei einem Kunden mit \u00fcber 10.000 Produktseiten gesehen, dass die Optimierung der Core Web Vitals (insbesondere LCP von 4,2 s auf 1,8 s) nicht nur zu einer 15% h\u00f6heren Indexierungsrate f\u00fchrte, sondern auch die organische Sichtbarkeit f\u00fcr Long-Tail-Keywords um 22% steigerte. Der Trick war nicht die 100-Punkte-Marke im PageSpeed Insights, sondern das Beheben von Render-blocking Ressourcen und das Optimieren der Bildkompression. Ein konkretes Beispiel: Das Vorladen kritischer CSS und das Verschieben von Drittanbieter-Skripten ans Ende des Bodys brachte den gr\u00f6ssten Sprung.<\/p><\/blockquote>\n Google verwendet drei Kernmetriken aus den Core Web Vitals, die Sie priorisieren sollten:<\/p>\n Das LCP misst die Ladezeit des gr\u00f6ssten sichtbaren Elements, z.B. eines Bildes oder eines Textblocks. Ein guter Wert liegt unter 2,5 Sekunden. In der Praxis sehen wir, dass Bildoptimierung (spezifisches Format wie WebP, korrekte Dimensionierung und Lazy Loading) der h\u00e4ufigste Engpass ist. Ein Server, der bei jedem Aufruf die Bilder dynamisch zuschneidet, kann hier Wunder wirken.<\/p>\n Das INP misst die Reaktionsf\u00e4higkeit auf Nutzereingaben. Ein guter Wert liegt unter 200 ms. Das Hauptproblem sind hier oft grosse JavaScript-Dateien, die im Hauptthread blockieren. Eine g\u00e4ngige L\u00f6sung: Deferring von nicht-notwendigen Skripten und die Verwendung von Intersection Observer f\u00fcr dynamische Inhalte. Aus unserer Erfahrung reicht es oft, das Laden von Tracking-Skripten und Chat-Widgets auf die Interaktion des Nutzers zu verschieben.<\/p>\n Das CLS misst die visuelle Stabilit\u00e4t. Ein Wert unter 0,1 ist gut. Die h\u00e4ufigste Ursache sind Bilder ohne explizite Abmessungen oder dynamisch eingef\u00fcgte Werbeanzeigen. Die L\u00f6sung hierf\u00fcr ist einfach: Der Prozess ist systematisch, aber erfordert keine Perfektion. F\u00fcr eine schnelle Analyse reichen folgende Tools:<\/p>\n Ein typischer Optimierungs-Workflow, den wir in Projekten anwenden: Messen Sie die aktuellen Werte mit PageSpeed Insights. Identifizieren Sie die gr\u00f6ssten Engp\u00e4sse (meistens Bilder oder JavaScript). Optimieren Sie diese gezielt. Messen Sie erneut. Der Fehler vieler Marketer ist, dass sie versuchen, alle 100 Optimierungsvorschl\u00e4ge umzusetzen. In der Realit\u00e4t bringen die ersten drei korrekt umgesetzten \u00c4nderungen 80% des Effekts.<\/p>\nIst die Seitengeschwindigkeit ein direkter Ranking-Faktor oder indirekt?<\/h2>\n
Welche Geschwindigkeitsmetriken sind f\u00fcr das Ranking am wichtigsten?<\/h2>\n
Largest Contentful Paint (LCP)<\/h3>\n
Interaction to Next Paint (INP) \/ First Input Delay (FID)<\/h3>\n
Cumulative Layout Shift (CLS)<\/h3>\n
width<\/code>– und height<\/code>-Attribute in HTML oder reservierte Platzhalter f\u00fcr dynamische Elemente. Das ist eine der wenigen SEO-Optimierungen, die wirklich \u00fcber Nacht Wirkung zeigen k\u00f6nnen.<\/p>\nWie misst und verbessert man die Seitengeschwindigkeit f\u00fcr SEO?<\/h2>\n
\n\n
\n \nTool<\/th>\n Was es misst<\/th>\n Wann man es verwendet<\/th>\n<\/tr>\n<\/thead>\n \n Google PageSpeed Insights<\/td>\n Lab-Daten und Felddaten (Chrome User Experience Report)<\/td>\n F\u00fcr erste Diagnosen und konkrete Optimierungsvorschl\u00e4ge<\/td>\n<\/tr>\n \n Google Search Console (Core Web Vitals)<\/td>\n Felddaten f\u00fcr echte Nutzer<\/td>\n F\u00fcr die Identifikation von Problemseiten auf der gesamten Domain<\/td>\n<\/tr>\n \n WebPageTest<\/td>\n Detailierte Wasserfall-Diagramme<\/td>\n F\u00fcr tiefgehende Fehleranalyse (z.B. aus welchem DNS die Ressourcen kommen)<\/td>\n<\/tr>\n \n Lighthouse (integriert in Chrome)<\/td>\n Lab-Leistungswerte<\/td>\n F\u00fcr lokale Tests w\u00e4hrend der Entwicklung<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n