Seitenladezeit und SEO: Was für Ihr Ranking 2026 wirklich zählt

Die Seitenladezeit beeinflusst Ihr Google-Ranking, aber anders, als viele Speed-Tests suggerieren. Google bewertet nicht eine einzelne Ladezeit in Sekunden, sondern drei Nutzererfahrungs-Messwerte aus echten Besuchen: Wie schnell erscheint der Hauptinhalt, wie schnell reagiert die Seite auf Klicks, und wie ruhig bleibt das Layout. Diese Core Web Vitals sind ein bestätigtes Rankingsignal, entscheiden aber meist erst dann, wenn Inhalte gleich gut sind. Für B2B-Websites ist Speed deshalb vor allem eine Frage von Anfragen und Vertrauen, erst danach eine Frage von Positionen. Hier erfahren Sie, welche Werte zählen, wie Sie richtig messen und welche Maßnahmen sich lohnen.

TL;DR

• Google misst die Ladezeit über drei Core Web Vitals: LCP bis 2,5 Sekunden, INP bis 200 Millisekunden und CLS bis 0,1 gelten als „gut“.
• Entscheidend sind Felddaten echter Nutzer (75. Perzentil), nicht der Lighthouse-Score im Labor.
• Speed ist ein Rankingfaktor unter vielen: Er hilft bei vergleichbarem Inhalt, ersetzt aber keine relevanten Inhalte.
• Für B2B zählt der Effekt auf Anfragen: Schnellere Seiten werden länger genutzt, Formulare müssen trotzdem überzeugen.
• Erst Indexierung und Technik-Grundlagen prüfen, dann Millisekunden jagen. Die richtige Reihenfolge spart Budget.

Inhaltsverzeichnis

• Wie stark beeinflusst die Ladezeit das Google-Ranking?
• Die drei Messwerte, die Google bewertet
• Felddaten und Labordaten: Warum 100 Punkte in Lighthouse nichts garantieren
• Was Pagespeed für B2B-Websites konkret bedeutet
• Die häufigsten Bremsen und was dagegen hilft
• Pagespeed-Optimierung in sechs Schritten
• Wenn die Ladezeit das kleinere Problem ist
• Unsere Sicht: Prioritäten statt Punktejagd
• Häufige Fragen
• Quellen

Wie stark beeinflusst die Ladezeit das Google-Ranking?

Google fasst die Nutzererfahrung auf einer Seite unter dem Begriff Page Experience zusammen. Laut der Dokumentation von Google Search Central zur Seitennutzerfreundlichkeit ist das kein einzelnes Signal, sondern ein Bündel: Core Web Vitals, HTTPS, Mobilfreundlichkeit und der Verzicht auf aufdringliche Interstitials. Google betont dort auch, dass relevante, hilfreiche Inhalte Vorrang haben. Eine schnelle Seite mit schwachem Inhalt überholt keine langsamere Seite, die die Suchanfrage besser beantwortet.

Das heißt nicht, dass Ladezeit egal ist. In umkämpften Suchergebnissen, in denen mehrere Anbieter ähnlich gute Inhalte liefern, kann die bessere Nutzererfahrung den Ausschlag geben. Wichtiger ist oft der indirekte Effekt: Wer lange auf eine Seite wartet, springt zurück zur Suche und klickt den nächsten Treffer. Das kostet Sie den Besucher, unabhängig davon, wie Google das wertet.

Ein zweiter Punkt wird oft übersehen: Google nutzt für Indexierung und Ranking die mobile Version Ihrer Website. Die Best Practices zur Mobile-First-Indexierung verlangen, dass mobile und Desktop-Version denselben Inhalt bieten. Eine Seite, die am Büro-Rechner flott lädt, auf dem Smartphone über Mobilfunk aber zäh ist, wird nach ihrer mobilen Leistung beurteilt. Genau dort verlieren viele B2B-Websites, weil sie intern fast nur am Desktop getestet werden.

Die drei Messwerte, die Google bewertet

Statt „Ladezeit in Sekunden“ arbeitet Google mit drei Kennzahlen. Die Grenzwerte stehen in der Google-Dokumentation zu Core Web Vitals und den Suchergebnissen:

INP hat im März 2024 den älteren Wert FID ersetzt. Das ist für viele Unternehmen relevant, weil INP die gesamte Nutzung einer Seite betrachtet und nicht nur die erste Interaktion. Websites mit schweren JavaScript-Frameworks, umfangreichen Cookie-Bannern oder vielen Drittanbieter-Skripten schneiden hier häufig schlechter ab als erwartet.

Wichtig ist, wie Google diese Werte auswertet. Laut web.dev zur Definition der Grenzwerte gilt eine Seite als „gut“, wenn 75 Prozent der Seitenaufrufe den Grenzwert erreichen, getrennt nach Mobilgeräten und Desktop. Ein schneller Test auf Ihrem Glasfaseranschluss sagt also wenig. Es zählt, was das langsamere Viertel Ihrer echten Besucher erlebt: der Einkäufer im Zug, der Techniker auf der Baustelle, der Entscheider auf einem älteren Firmen-Laptop.

Felddaten und Labordaten: Warum 100 Punkte in Lighthouse nichts garantieren

Die meisten Speed-Diskussionen drehen sich um den Performance-Score aus Lighthouse oder PageSpeed Insights. Dieser Score ist ein Labortest: ein simulierter Seitenaufruf mit festgelegtem Gerät und Netzwerk. Er ist nützlich, um Ursachen zu finden, aber er ist nicht das, was Google für das Ranking heranzieht.

Für die Suche zählen Felddaten aus dem Chrome User Experience Report (CrUX), also Messungen echter Chrome-Nutzer über die letzten 28 Tage. Die Übersicht zu Web Vitals auf web.dev erklärt, welche Tools welche Datenart zeigen. In der Praxis heißt das:

• PageSpeed Insights zeigt oben Felddaten (sofern Ihre Seite genug Traffic hat) und darunter den Labortest. Lesen Sie zuerst den oberen Teil.
• Google Search Console bündelt im Bericht „Core Web Vitals“ Felddaten für Gruppen ähnlicher URLs. Das ist die beste Sicht auf die gesamte Website.
• Lighthouse in Chrome DevTools eignet sich für Entwickler, um eine konkrete Änderung vor und nach dem Deployment zu vergleichen.

Deshalb kommt es regelmäßig vor, dass eine Seite im Labor 95 Punkte erreicht und trotzdem in der Search Console als „schlecht“ geführt wird, oder umgekehrt. Kleinere B2B-Websites haben zudem oft zu wenig Traffic für eigene CrUX-Daten auf URL-Ebene. Dann greift Google auf Werte für die gesamte Domain zurück, und einzelne langsame Seitentypen wie Produktkataloge oder Whitepaper-Landingpages ziehen den Durchschnitt nach unten.

Was Pagespeed für B2B-Websites konkret bedeutet

Die bekannteste Studie zum Geschäftseffekt von Speed ist der Report „Milliseconds Make Millions“, den Deloitte im Auftrag von Google 2019 veröffentlicht hat. Laut dem Report bei Think with Google stiegen die Conversions bei einer um 0,1 Sekunden schnelleren mobilen Website im Handel um 8 Prozent und im Reisebereich um 10 Prozent.

Für B2B ist ein anderes Detail aus derselben Studie aufschlussreicher. Bei Lead-Generierungs-Websites stiegen die Seitenaufrufe pro Sitzung um rund 7 Prozent, die mobile Conversion-Rate sank dagegen um fast 2 Prozent. Das ist eine ehrliche Erinnerung: Speed bringt Besucher dazu, mehr von Ihrer Website zu sehen. Ob daraus eine Anfrage wird, entscheiden Angebot, Inhalt und Formular. Eine schnelle Seite mit einem zwölfteiligen Kontaktformular bleibt eine Hürde.

Typische B2B-Situationen, in denen Ladezeit wirklich Geld kostet:

• Paid- und SEO-Landingpages für Fachbegriffe, bei denen Sie mit wenigen Anbietern um sehr spezifische Suchanfragen konkurrieren. Hier ist die Nutzererfahrung tatsächlich ein Unterscheidungsmerkmal.
• Produkt- und Lösungsseiten mit schweren Medien, etwa 3D-Viewern, Videos im Hero-Bereich oder großen Bildergalerien.
• Websites auf React, Next.js oder anderen JavaScript-Frameworks, bei denen viel Code im Browser ausgeführt wird, bevor Nutzer interagieren können.
• Seiten mit vielen Marketing-Skripten: Tag-Manager, Tracking, Chat-Widgets, Heatmaps und Consent-Tools summieren sich schnell zu einem INP-Problem.

Hinzu kommt ein Thema, das in Deutschland seit Juni 2025 viele Unternehmen beschäftigt: das Barrierefreiheitsstärkungsgesetz. Performance und Barrierefreiheit überschneiden sich, denn stabile Layouts, sauberes HTML und schlankes JavaScript helfen auch Screenreadern und anderen assistiven Technologien. Wer ohnehin an der Barrierefreiheit arbeitet, sollte Performance im selben Zug mitdenken. Ob und in welchem Umfang das Gesetz für Ihr Angebot gilt, klären Sie am besten mit einer auf IT-Recht spezialisierten Kanzlei.

Die häufigsten Bremsen und was dagegen hilft

Langsamer Hauptinhalt (LCP)

LCP ist in der Praxis der Wert, an dem die meisten Websites hängen bleiben. Die Ursache liegt selten an einer einzigen Stelle, sondern in einer Kette: Der Server antwortet träge, dann blockieren CSS und Skripte das Rendering, und zuletzt wird ein unkomprimiertes Hero-Bild geladen.

Was hilft:

• Hero-Bilder in modernen Formaten wie WebP oder AVIF ausliefern, in passender Größe für das jeweilige Gerät.
• Das LCP-Element per fetchpriority="high" oder Preload priorisieren und es auf keinen Fall per Lazy Loading verzögern.
• Serverantwortzeit senken: Caching, ein CDN und bei Frameworks wie Next.js serverseitiges Rendering oder statische Generierung für Seiten, die sich selten ändern.
• Kritisches CSS inline ausliefern und den Rest nachladen.

Träge Reaktion auf Klicks (INP)

Schlechte INP-Werte entstehen, wenn der Browser mit JavaScript beschäftigt ist, während der Nutzer klickt. Lösungsansätze sind ungenutztes JavaScript zu entfernen, große Bundles aufzuteilen, lange Tasks zu zerlegen und Drittanbieter-Skripte kritisch zu prüfen. Jedes Tracking-Tool, das niemand mehr auswertet, ist reine Last.

Verrutschendes Layout (CLS)

CLS lässt sich meist mit wenig Aufwand beheben: feste Breiten und Höhen für Bilder, Videos und Anzeigen-Slots, reservierter Platz für Cookie-Banner und eingeblendete Hinweise sowie eine saubere Einbindung von Web-Fonts mit font-display und passenden Ersatzschriften.

Lazy Loading mit Nebenwirkungen

Lazy Loading ist eine gute Praxis, kann aber Inhalte vor Google verstecken. Die Google-Anleitung zu Lazy-Loaded-Inhalten stellt klar, dass relevante Inhalte geladen werden müssen, sobald sie im Viewport sichtbar sind, und nicht erst nach Klick, Scroll-Event oder Tastatureingabe. Wer Texte, Produktdetails oder Bilder nur nach Nutzeraktion nachlädt, spart zwar Ladezeit, riskiert aber, dass Google sie nie sieht. Mehr dazu, wie Sie dynamische Seiten indexierbar halten, lesen Sie in unserem Beitrag zu JavaScript SEO für dynamische Websites.

Pagespeed-Optimierung in sechs Schritten

Eine Reihenfolge, die sich in Projekten bewährt, weil sie Aufwand und Wirkung zusammenbringt:

1. Ausgangslage mit Felddaten erfassen. Öffnen Sie in der Search Console den Bericht „Core Web Vitals“ und notieren Sie, welche URL-Gruppen mobil und am Desktop als „schlecht“ oder „Optimierung erforderlich“ markiert sind.
2. Seiten nach Geschäftswert sortieren. Eine langsame Lösungsseite, über die Anfragen kommen, ist wichtiger als ein langsamer Pressebereich. Kombinieren Sie die Speed-Daten mit Traffic und Conversions aus Ihrer Webanalyse.
3. Ursachen im Labor finden. Testen Sie repräsentative URLs je Seitentyp in PageSpeed Insights und Lighthouse. Notieren Sie das LCP-Element, die größten Skripte und die Quellen von Layoutverschiebungen.
4. Maßnahmen nach Aufwand und Wirkung priorisieren. Bildkomprimierung und feste Bildmaße sind oft in Stunden erledigt. Ein Umbau auf serverseitiges Rendering dauert Wochen. Starten Sie mit dem, was viele Seiten auf einmal verbessert, etwa Templates und globale Skripte.
5. Umsetzen und vor dem Livegang prüfen. Testen Sie Änderungen in einer Staging-Umgebung, aber achten Sie darauf, dass keine Noindex-Tags oder Sperren aus der Testumgebung mit live gehen.
6. 28 Tage später erneut messen. Felddaten reagieren verzögert, weil CrUX einen rollierenden Zeitraum betrachtet. Bewerten Sie den Erfolg erst danach und richten Sie ein Monitoring ein, damit neue Skripte oder Plugins die Werte nicht still wieder verschlechtern.

Wenn die Ladezeit das kleinere Problem ist

Viele Unternehmen kommen mit der Frage nach Pagespeed zu uns und haben eigentlich ein anderes Problem. Wenn wichtige Seiten gar nicht im Index sind, hilft keine Millisekunde. Typische Fälle, die wir vor jeder Speed-Optimierung ausschließen:

• Falsche oder fehlende Canonical-Tags, sodass Google eine andere URL als die gewünschte rankt.
• Noindex-Tags, die nach einem Relaunch aus der Staging-Umgebung übernommen wurden.
• Eine robots.txt, die wichtige Verzeichnisse oder Ressourcen wie CSS und JavaScript blockiert. Wie Sie das sauber steuern, zeigt unser Beitrag zu robots.txt für SEO.
• Fehlende hreflang-Verknüpfungen bei mehrsprachigen Websites, gerade bei B2B-Unternehmen mit DACH- und internationalen Versionen.
• Client-seitig gerenderte Inhalte, die Google nur verzögert oder unvollständig erfasst.

Erst wenn diese Grundlagen stehen, entfaltet eine schnellere Seite ihre Wirkung. Eine vollständige Prüfliste mit Priorisierung finden Sie in unserer Checkliste für den technischen SEO-Audit.

Unsere Sicht: Prioritäten statt Punktejagd

Wir sehen regelmäßig Teams, die Wochen in einen perfekten Lighthouse-Score investieren, während die Search Console unverändert Felddaten im roten Bereich zeigt oder zentrale Seiten gar nicht indexiert sind. Das ist verständlich, denn eine Zahl von 0 bis 100 fühlt sich messbar an. Sie ist nur nicht das Ziel.

Unser Ansatz ist eine klare Priorisierung: Welche Seiten bringen Ihnen Anfragen, welche davon fallen bei echten Nutzern durch, und welche Ursache lässt sich mit dem geringsten Aufwand für die meisten URLs beheben? Daraus entsteht keine generische To-do-Liste mit 80 Punkten, sondern eine kurze Reihenfolge mit messbaren KPIs.

Weil wir technisches SEO mit Erfahrung in modernen Webtechnologien wie React und Next.js verbinden, sprechen wir die Sprache Ihrer Entwickler. Wir können erklären, warum ein bestimmtes Bundle den INP-Wert belastet, und gemeinsam entscheiden, ob serverseitiges Rendering, Code-Splitting oder einfach das Entfernen eines alten Skripts der richtige Hebel ist. Datenbasierte, AI-gestützte Workflows helfen uns, Muster über viele URLs schnell zu erkennen. Die Entscheidung, was zuerst passiert, treffen wir trotzdem mit Ihnen, nicht ein Tool.

Und wir versprechen keine Rankings. Eine schnellere Website ist eine bessere Grundlage, mehr nicht und nicht weniger. Was sie bringt, zeigen die Zahlen nach der Umsetzung.

— Aliniyaz

Wenn Sie wissen möchten, wo Ihre Website bei Ladezeit, Indexierung und Technik wirklich steht, ist unser Einstiegspaket SEO Foundation ab 999 € einmalig der strukturierte erste Schritt, ohne lange Vertragsbindung. Für laufende Betreuung gibt es monatliche Pakete ab SEO Essentials. Alle Details finden Sie auf unserer Seite mit den Preisen und Paketen, und wie wir an Performance und Indexierung herangehen, beschreibt die Seite zu Technical SEO.

Häufige Fragen

Was ist eine gute Seitenladezeit für SEO?

Google bewertet keine einzelne Ladezeit in Sekunden, sondern die Core Web Vitals. Als „gut“ gilt ein LCP von höchstens 2,5 Sekunden, ein INP von höchstens 200 Millisekunden und ein CLS von höchstens 0,1, jeweils für 75 Prozent der echten Seitenaufrufe. Wenn Ihre Seite diese Werte mobil erreicht, sind Sie auf einem soliden Stand.

Warum lädt meine Website so langsam?

Die häufigsten Ursachen sind zu große Bilder, eine langsame Serverantwort, viel JavaScript und zahlreiche Drittanbieter-Skripte wie Tracking, Chat oder Consent-Tools. Oft summieren sich mehrere kleine Bremsen. PageSpeed Insights zeigt im Diagnosebereich, welche Dateien und Skripte am meisten Zeit kosten.

Wie lange dauert es, bis sich eine Pagespeed-Optimierung zeigt?

Die Felddaten in Search Console und PageSpeed Insights beruhen auf einem rollierenden Zeitraum von 28 Tagen. Verbesserungen werden dort also erst nach rund vier Wochen vollständig sichtbar. Ob und wie stark sich das auf Rankings auswirkt, hängt vom Wettbewerb und von der Qualität Ihrer Inhalte ab.

Reicht ein Lighthouse-Score von 90 oder mehr?

Nein, nicht als alleiniges Ziel. Lighthouse ist ein Labortest unter festen Bedingungen, Google nutzt für das Ranking Felddaten echter Nutzer. Ein hoher Score ist ein gutes Zeichen, entscheidend ist aber, ob der Core-Web-Vitals-Bericht in der Search Console Ihre wichtigen Seiten als „gut“ führt.

Quellen

• Google Search Central: Seitennutzerfreundlichkeit in den Google-Suchergebnissen
• Google Search Central: Best Practices zur Mobile-First-Indexierung
• Google Search Central: Core Web Vitals und Google-Suchergebnisse
• web.dev: So wurden die Grenzwerte für die Core Web Vitals definiert
• web.dev: Web Vitals
• Deloitte/Google: Milliseconds Make Millions (Think with Google)
• Google Search Central: Lazy-Loaded-Inhalte korrigieren

Empfehlungen

• Technisches SEO: Technik, Indexierung & Performance
• Technischer SEO Audit: Checkliste und Priorisierung für 2026
• SEO-Prozess: Analyse, Priorisierung, Umsetzung, Messung
• Nachhaltige monatliche SEO-Optimierung