Was ist Lazy Loading? Wirkung auf SEO und Ladezeit

Lazy Loading ist eine Technik, bei der der Browser Bilder, iframes und andere Einbettungen erst lädt, wenn Besucher in ihre Nähe scrollen. Seit 2012 arbeite ich an Ladezeit und SEO Problemen auf Kundenseiten. Dabei gehört Lazy Loading zu den Dingen, die ich am häufigsten falsch eingerichtet sehe. In diesem Beitrag zeige ich den richtigen Einsatz, den teuersten Fehler und die Erwartungen von Google.

Den allgemeinen Zusammenhang zwischen Geschwindigkeit und Ranking beschreibe ich im Beitrag wie die Ladezeit SEO beeinflusst. Hier bleibt der Fokus eng: Welche Elemente dürfen warten, welche niemals, und wie liest eine Suchmaschine das Ergebnis?

Was ist Lazy Loading und wie funktioniert es?

Lazy Loading bedeutet, dass der Browser Ressourcen außerhalb des sichtbaren Bereichs, also Bilder, iframes und Videos, nicht beim Seitenaufruf lädt, sondern erst dann, wenn Nutzer in ihre Nähe scrollen. Deshalb lädt der erste Aufruf weniger Daten, und der Browser konzentriert sich auf sichtbare Inhalte.

Das Prinzip ist einfach. Normalerweise fordert der Browser jedes img Tag sofort an, das er beim Lesen des HTML findet. Sogar ein Logo im Footer konkurriert dann in den ersten Sekunden um Bandbreite, obwohl viele Besucher den Footer nie erreichen. Lazy Loading setzt diese Ressourcen stattdessen auf eine Warteliste.

Während Nutzer scrollen, prüft der Browser, wie nah ein wartendes Element dem sichtbaren Bereich kommt. Ab einer bestimmten Distanz startet der Download. Bei einer sauberen Umsetzung merkt der Besucher also keine Verzögerung, denn das Bild ist fertig, bevor es den Bildschirm erreicht.

Mir ist das Thema wichtig, weil lange Kategorieseiten, Blogartikel und Produktgalerien oft Dutzende Bilder enthalten. Allerdings sehen viele Besucher nur den oberen Teil einer Seite. Jedes Bild, das niemand anschaut, kostet somit Servertraffic und mobiles Datenvolumen.

Welche Probleme löst Lazy Loading konkret?

Der Nutzen wächst mit der Länge der Seite und der Menge an Medien. Auf einer kurzen Leistungsseite bleibt der Unterschied klein. Auf einer Kategorieseite mit Hunderten Produktkarten ist der Effekt dagegen deutlich.

• Die Datenmenge beim ersten Aufruf sinkt.
• Der Browser nutzt seine Verbindungen für Ressourcen im sichtbaren Bereich.
• Mobile Besucher verbrauchen kein Datenvolumen für Inhalte, die sie nie sehen.
• Server und CDN liefern weniger Bilder aus, die niemand betrachtet.
• Schwere Einbettungen von Drittanbietern, etwa Karten oder Videoplayer, blockieren den ersten Aufruf nicht mehr.

Eine Unterscheidung ist mir hier wichtig. Lazy Loading ist ein Werkzeug zur Priorisierung, kein Werkzeug zur Komprimierung. Es macht ein Bild nicht kleiner, sondern entscheidet nur über den Zeitpunkt des Downloads. Erwarten Sie deshalb nicht, dass es allein jedes Ladezeitproblem löst.

Wie setzen Sie das Attribut loading="lazy" ein?

Meine erste Wahl ist heute das native Attribut des Browsers. Sobald Sie loading="lazy" in ein img oder iframe Tag schreiben, steuert der Browser das Verzögern selbst. Eine zusätzliche JavaScript Bibliothek brauchen Sie dafür nicht.

Das Attribut kennt drei Werte:

1. lazy: Der Browser verschiebt den Download, bis sich das Element dem sichtbaren Bereich nähert.
2. eager: Der Browser lädt das Element sofort, egal wo es steht.
3. auto: Der Browser entscheidet; in der Praxis verhält er sich wie bei eager.

Ohne Attribut behandelt der Browser ein Bild als eager. Die MDN Dokumentation beschreibt das Verhalten im Detail. Zudem unterstützen aktuelle Versionen von Chrome, Edge, Firefox und Safari das Attribut.

In der Praxis halte ich mich an zwei Regeln. Erstens bekommt jedes Bild mit lazy feste Angaben für width und height. Zweitens setze ich das Attribut nie blind auf das gesamte Template. Bilder im oberen Bereich brauchen eine eigene Behandlung, und die nächsten Abschnitte erklären, warum.

Wann beginnt der Browser, ein Lazy Loading Bild zu laden?

Der Browser wartet nicht, bis ein Bild vollständig im Bild ist. Stattdessen startet er die Anfrage etwas früher. Laut dem Leitfaden des Chrome Teams auf web.dev hängt diese Distanz von der Verbindungsgeschwindigkeit ab.

Derselbe Leitfaden beschreibt, dass Chrome diese Schwellen mit der Zeit angepasst hat. Aktuell nutzt Chrome bei schnellen Verbindungen etwa 1250 Pixel und bei langsameren etwa 2500 Pixel. Diese Werte können sich allerdings mit neuen Browserversionen ändern. Schreiben Sie sie daher nicht fest in Ihre eigene Logik.

Was heißt das für Sie? Wer in normalem Tempo scrollt, sieht selten eine leere Fläche. Bei sehr schnellem Scrollen oder schwacher Verbindung kann ein Bild aber einen Moment später erscheinen. Genau deshalb sind width und height so wichtig: Der Browser reserviert den Platz vorab, und das Layout springt nicht.

Mein Fazit aus der Praxis: Natives Lazy Loading arbeitet ausgewogener als die meisten älteren JavaScript Bibliotheken. Denn der Browser kennt die Netzbedingungen besser als Ihr Skript und passt die Schwelle entsprechend an.

Warum sollten Sie das LCP Bild nie per Lazy Loading laden?

Das ist der häufigste und teuerste Fehler, den ich sehe. LCP bezeichnet den Moment, in dem das größte Element im sichtbaren Bereich fertig gerendert ist. Auf den meisten Websites ist das das Hero Bild. Mit loading="lazy" fordert der Browser dieses Bild nicht sofort an. Zunächst berechnet er das Layout, dann erkennt er, dass das Bild im sichtbaren Bereich liegt, und erst danach startet der Download.

Somit wird Ihr wichtigstes Bild zu einem der letzten, die der Browser entdeckt. Eine Auswertung auf web.dev betrachtet die Phase, in der WordPress standardmäßig alle Bilder verzögert geladen hat. Seiten mit verzögertem LCP Bild zeigten dabei schlechtere LCP Werte. WordPress hat den Standard danach so geändert, dass die ersten Bilder ausgenommen sind.

Meine Regel ist klar: Kein Bild, das im ersten Bildschirm erscheint, bekommt lazy. Beim Hero Bild gehe ich so vor:

• Ich entferne das loading Attribut oder setze eager.
• Mit fetchpriority="high" signalisiere ich dem Browser die Priorität.
• Das Bild steht direkt im HTML und nicht in einem nachgeladenen Skript.
• Statt eines CSS Hintergrunds nutze ich ein img Tag, damit der Browser es früh findet.

Kurz gesagt: Lazy Loading beschleunigt den unteren Teil einer Seite, oben wirkt es dagegen wie eine Bremse.

Am einfachsten erkennen Sie den Fehler, wenn Sie den Quelltext in der mobilen Ansicht öffnen und das Tag des Hero Bildes prüfen. Außerdem nutzen viele Themes getrennte Hero Bilder für Desktop und Smartphone, also prüfen Sie beide.

Welche Bilder sollten Sie verzögert laden und welche sofort?

Für die Entscheidung zählt der erste Bildschirm, also der Bereich ohne Scrollen. Dieser Bereich hängt allerdings vom Gerät ab. Am Desktop sehen Besucher vielleicht vier Produktkarten, am Smartphone nur eine. Deshalb prüfe ich Mobil und Desktop immer getrennt.

Eine praktische Methode: Führen Sie im Template einen Zähler und setzen Sie die ersten zwei oder drei Bilder auf eager, alle weiteren auf lazy. Diese Zahl ist ein Startwert aus der Praxis und keine Garantie. Testen Sie sie also an Ihrem eigenen Layout.

Kann Google Inhalte mit Lazy Loading sehen?

Ja, sofern die Umsetzung stimmt. Google erklärt das in den Search Central Richtlinien zu Lazy Loading sehr deutlich. Ein Detail ist dabei entscheidend: Der Googlebot scrollt nicht, klickt nicht und tippt nicht wie ein Mensch.

Stattdessen vergrößert Google beim Rendern den sichtbaren Bereich zu einem sehr hohen Fenster. Lädt Ihr Inhalt also, sobald er sichtbar wird, sieht der Googlebot ihn. Wartet der Inhalt dagegen auf eine Nutzeraktion wie ein Scroll Event oder einen Klick, löst der Googlebot diese Aktion nie aus. Folglich fehlt der Inhalt in der gerenderten Seite.

Google empfiehlt folgende Wege:

• Nutzen Sie das native Attribut loading="lazy".
• Falls Sie JavaScript brauchen, wählen Sie eine Lösung auf Basis der IntersectionObserver API.
• Vermeiden Sie ältere Bibliotheken, die auf Scroll Events reagieren.
• Geben Sie jedem Abschnitt eines Infinite Scroll eine eigene, dauerhafte URL.

Deshalb stelle ich in jedem Audit zuerst dieselbe Frage: Wartet dieser Inhalt auf eine Aktion des Nutzers oder nur darauf, sichtbar zu werden? Im ersten Fall besteht ein SEO Risiko.

Welche SEO Probleme kann Lazy Loading verursachen?

Eine korrekte Umsetzung ist suchmaschinenfreundlich. Eine fehlerhafte richtet dagegen stillen Schaden an, denn Nutzer sehen eine vollständige Seite, die Suchmaschine aber nicht. Diese Fehler finde ich am häufigsten:

1. Leeres src Attribut: Die echte Adresse steht nur in einem Datenattribut. Scheitert das Skript, lädt das Bild nie.
2. Verzögert geladener Text: Produktbeschreibungen oder Bewertungen hängen an einem Scroll Event, also übersieht der Googlebot sie womöglich.
3. Kein noscript Fallback: Ältere JavaScript Lösungen verzichten darauf, und das Bild erreicht den Index nicht.
4. Infinite Scroll ohne URLs: Spätere Produktgruppen haben keine Adresse, deshalb erreicht der Crawler sie nicht.
5. Ein LCP Bild mit lazy: Das verschlechtert Ihre Ladezeitsignale direkt.

Lazy Loading selbst bringt allerdings keine Rankingstrafe mit sich. Nicht die Technik ist das Problem, sondern die Umsetzung. Die ehrliche Antwort auf die Frage nach dem SEO Schaden lautet also: nur bei falscher Einrichtung. Die meisten dieser Fehler finden Sie bei einer gründlichen Prüfung im technischen SEO.

Verursacht Lazy Loading Layout Shifts (CLS)?

Das kann passieren, allerdings liegt die Ursache in fehlenden Größenangaben und nicht in der Technik. CLS misst unerwartete Verschiebungen von Elementen während des Ladens. Kommt ein Bild spät und kennt der Browser seine Größe nicht, schiebt es beim Erscheinen den Text darunter nach unten.

Die Lösung ist einfach. Schreiben Sie in jedes img Tag die echten Werte für width und height. Moderne Browser berechnen daraus das Seitenverhältnis und reservieren die passende Höhe, bevor das Bild ankommt. Somit bleibt der Platzhalter auch bei flexibler Breite im CSS korrekt.

Alternativ legen Sie das Seitenverhältnis direkt im CSS fest. Vor allem bei Kartenlayouts mit unterschiedlichen Bildformaten hilft das. Dieselbe Regel gilt zudem für iframes: Ohne festes Seitenverhältnis springt die Seite, sobald das iframe lädt.

Dieses Muster sehe ich oft. Ein Team aktiviert Lazy Loading, der Ladezeitwert steigt leicht, und CLS verschlechtert sich. Dann gibt das Team Lazy Loading die Schuld und schaltet es ab. Tatsächlich fehlten aber nur die Größenangaben im Template. Die Balance zwischen Tempo und Nutzererlebnis beschreibe ich ausführlicher im Beitrag zu SEO und Nutzererfahrung.

Wie laden Sie iframes und Videos verzögert?

iframes sind meist deutlich schwerer als Bilder. Eine einzige YouTube Einbettung bringt eigene Skripte, Stylesheets und Schriften mit. Deshalb empfehle ich loading="lazy" für jedes iframe unterhalb des ersten Bildschirms. Der Leitfaden zu iframes auf web.dev bestätigt, dass das Attribut auch hier Standard ist.

Eine fortgeschrittene Option ist eine Fassade. Statt des echten Players zeigen Sie das Vorschaubild des Videos mit einem Play Button. Erst beim Klick lädt die Seite das echte iframe. So laden Besucher, die das Video nie starten, auch den schweren Playercode nie.

Beim video Tag sieht es anders aus, denn es unterstützt das loading Attribut nicht. Stattdessen nutze ich diese Einstellungen:

• Mit preload="none" oder preload="metadata" verhindere ich einen frühen Download der Datei.
• Ein leichtes poster Bild sorgt für die erste Ansicht.
• Auf automatisch startende Hintergrundvideos im ersten Bildschirm verzichte ich möglichst.

Eine Fassade kann allerdings SEO kosten. Für Video Rich Results und Signale einer Videoseite muss Google das Video finden. Ist das Video also der Hauptinhalt der Seite, ergänzen Sie strukturierte Daten für das Video zusätzlich zur Fassade.

Natives Lazy Loading oder JavaScript Bibliothek?

Für die meisten Projekte lautet meine Antwort heute: nativ. Das eingebaute Attribut braucht keinen zusätzlichen Code und belastet den Main Thread nicht. Zudem entspricht es der Methode, die Google empfiehlt. Trotzdem hat JavaScript in einigen Fällen noch seinen Platz.

Zu JavaScript greife ich nur in drei Situationen. Erstens, wenn ich CSS Hintergrundbilder verzögern muss. Zweitens, wenn eine Komponente beim Sichtbarwerden weitere Aktionen auslösen soll. Drittens, wenn ein Projekt eine sehr spezielle Ladedistanz braucht. Bibliotheken, die auf Scroll Events hören, empfehle ich dagegen nicht mehr, weil sie die Performance bremsen und die Kompatibilität mit dem Googlebot gefährden.

Wie richten Sie Lazy Loading in WordPress und Baukastensystemen ein?

WordPress ergänzt seit Version 5.5 automatisch loading="lazy" an Bildern. Spätere Versionen nehmen zudem die ersten Inhaltsbilder davon aus. Der WordPress Kern erledigt diese Aufgabe also weitgehend richtig.

Probleme entstehen meist durch Plugins und Themes. Ein Muster sehe ich häufig: Der Kern setzt natives Lazy Loading, ein Speed Plugin fügt eine eigene JavaScript Lösung hinzu, und das Theme nutzt für den Slider eine dritte Methode. Dann steuern drei Mechanismen dasselbe Bild, und das Hero Bild landet womöglich versehentlich in der Warteschlange.

Auf jeder Plattform empfehle ich diese Prüfung:

1. Öffnen Sie den Quelltext und suchen Sie das img Tag des Hero Bildes.
2. Achten Sie auf loading="lazy", ein Datenattribut mit der Bildadresse oder andere Hinweise auf Verzögerung.
3. Sind mehrere Plugins oder Einstellungen für Lazy Loading aktiv, behalten Sie nur eines.
4. Bietet das Plugin die Option, die ersten Bilder auszunehmen, richten Sie diese am mobilen Layout aus.

Bei gehosteten Shopsystemen wie Shopify ist der Zugriff auf den Themecode oft begrenzt. Vereinbaren Sie dann mit dem Themeentwickler eine eigene Regel für das Hero Bild und die ersten Produktkarten. In der Praxis kostet genau diese Abstimmung bei E-Commerce Projekten viel Zeit.

Wie passen Infinite Scroll und Lazy Loading zusammen?

Infinite Scroll ist Lazy Loading auf Inhaltsebene: Während Nutzer scrollen, hängt die Seite neue Produkte oder Beiträge an. Für Nutzer fühlt sich das flüssig an. Für Suchmaschinen entsteht allerdings ein echtes Risiko, denn der Googlebot scrollt nicht und sieht womöglich nichts nach der ersten Gruppe.

Googles Haltung ist eindeutig: Jeder Inhaltsabschnitt braucht eine eigene, dauerhafte URL. In der Praxis baue ich das so auf:

• Im Hintergrund bleibt eine klassische Paginierung bestehen, etwa kategorie/seite/2 und kategorie/seite/3.
• Beim Scrollen lade ich die nächste Gruppe und aktualisiere die Adresszeile über die History API.
• Jede Seite der Paginierung funktioniert auch bei direktem Aufruf.
• Normale a Tags verlinken die Seiten der Paginierung untereinander.

So erleben Nutzer den unendlichen Scroll, und der Googlebot crawlt jede Gruppe als eigene Seite. Bei großen Katalogen ist das besonders wichtig. Zudem finden Nutzer nach dem Besuch eines Produkts wieder genau an ihre alte Stelle zurück.

Wie testen Sie Probleme mit Lazy Loading?

Ich verlasse mich nie auf ein einzelnes Werkzeug, weil jedes eine andere Frage beantwortet. Meine Reihenfolge sieht so aus:

1. Lighthouse: Ich achte auf die Warnung zu einem verzögert geladenen LCP Bild und auf den Hinweis, Bilder außerhalb des Bildschirms zu verzögern. Den kompletten Ablauf zeige ich im Leitfaden zum Lighthouse Test.
2. URL Prüfung in der Search Console: Ich starte einen Live Test und kontrolliere, ob die Bilder im gerenderten HTML und im Screenshot erscheinen.
3. Entwicklertools im Browser: Im Network Tab beobachte ich, welche Bilder vor dem Scrollen laden.
4. Test ohne JavaScript: Ich deaktiviere Skripte und prüfe, ob die wichtigen Bilder weiterhin erscheinen.

Die Kontrolle des gerenderten HTML in der Search Console ist dabei am wichtigsten. Denn dort sehen Sie, was Google tatsächlich liest. Fehlen dort Produktbilder oder Bewertungstexte, ist die Seite für die Suchmaschine unvollständig, egal wie gut sie für Nutzer aussieht.

Beeinflusst Lazy Loading den Traffic aus der Google Bildersuche?

Bei korrekter Umsetzung nicht. Google braucht die Adresse eines Bildes, um es zu indexieren. Mit nativem loading="lazy" steht die echte Adresse im src Attribut, also findet Google das Bild problemlos.

Das Risiko entsteht bei älteren JavaScript Lösungen. Sie setzen einen winzigen Platzhalter in src und verstecken die echte Adresse in einem Datenattribut. Läuft das Skript, funktioniert alles. Scheitert es jedoch oder startet beim Rendern nicht, sieht Google nur den Platzhalter.

Für Websites mit Traffic aus der Bildersuche empfehle ich deshalb einige Sicherungen. Lassen Sie die echte Adresse immer in src stehen. Nehmen Sie wichtige Bilder in eine Bild Sitemap auf und schreiben Sie beschreibende Alt Texte. Prüfen Sie zudem regelmäßig, ob Produktbilder im gerenderten HTML erscheinen. Dateigröße und Format sind ein eigenes Thema, auf das ich hier nicht eingehe. Für eine passend skalierte Datei hilft Ihnen das Werkzeug Bild verkleinern.

Was ist der Unterschied zwischen Lazy Loading und Preload?

Die beiden Techniken sind Gegenteile, trotzdem verwechseln viele sie ständig. Lazy Loading verzögert eine Ressource, Preload zieht sie nach vorne. Das eine sagt dem Browser „noch nicht anfordern“, das andere „jetzt anfordern, du brauchst es gleich“.

Preload nutze ich vor allem für kritische Ressourcen, die der Browser sonst spät entdeckt. Ist zum Beispiel ein CSS Hintergrundbild das LCP Element, findet der Browser es erst nach dem Lesen des Stylesheets. Dann ergänze ich eine preload Zeile im head. Andererseits ist es ebenso ein Fehler, alles vorzuladen, denn jede vorgezogene Datei konkurriert mit anderen wichtigen Dateien um Bandbreite.

Die richtige Aufteilung lautet also: das kritische Bild im ersten Bildschirm vorziehen, die Bilder darunter verzögern. Dasselbe Bild gleichzeitig mit preload und lazy auszustatten, sendet widersprüchliche Signale. Auch diese Kombination finde ich in Audits immer wieder.

Warum wirkt Lazy Loading mobil stärker?

Auf Smartphones ist der Bildschirm klein und die Verbindung oft schwankend. Am Desktop sehen Besucher im ersten Bildschirm vielleicht vier Produktkarten, am Smartphone nur eine. Folglich gibt es mobil deutlich mehr Bilder, die warten dürfen.

Zudem surfen mobile Besucher häufig mit begrenztem Datenvolumen. Eine Galerie herunterzuladen, die sie nie sehen, kostet sie echtes Geld. Deshalb treffe ich Entscheidungen zum Lazy Loading zuerst anhand des mobilen Layouts und prüfe danach den Desktop. Wie Sie die mobile Darstellung insgesamt prüfen, beschreibe ich im Beitrag zum Test der Mobilfreundlichkeit.

Mobil lauert allerdings auch eine Falle. Eine Regel wie „die ersten drei Bilder eager“, die für den Desktop gedacht ist, zieht am Smartphone womöglich zu viele Bilder vor. Umgekehrt passiert es ebenso: Ein Bild im ersten mobilen Bildschirm erhält lazy, weil es im Desktop Template weiter unten steht. Testen Sie also beide Layouts getrennt.

Welche Schritte sollten Sie beim Einrichten von Lazy Loading befolgen?

Ob neues Projekt oder bestehende Website, ich gehe immer in derselben Reihenfolge vor. Diese Liste ist keine Garantie, sondern eine Routine, die sich in der Praxis bewährt hat:

1. Listen Sie für jeden Templatetyp (Startseite, Kategorie, Produkt, Blog) die Bilder im ersten mobilen Bildschirm auf.
2. Entfernen Sie bei diesen Bildern lazy und ergänzen Sie fetchpriority="high" beim LCP Bild.
3. Setzen Sie loading="lazy" bei allen übrigen Bildern und iframes.
4. Ergänzen Sie width und height in jedem img Tag.
5. Entfernen Sie überlappende Plugins oder skriptbasierte Lösungen.
6. Hängt Text an einem Scroll oder Klick Event, liefern Sie ihn stattdessen direkt im HTML aus.
7. Bei Infinite Scroll richten Sie URLs für die Paginierung ein.
8. Testen Sie mit dem Live Test der Search Console und mit Lighthouse, dann beobachten Sie die Felddaten einige Wochen lang.

Die Reihenfolge ist mir wichtig, weil der größte Gewinn meist aus den ersten beiden Schritten kommt. Überspringen Sie dennoch den letzten Schritt nicht. Ein Labortest liefert nur eine Momentaufnahme von einem Gerät, die Felddaten zeigen dagegen das Erlebnis echter Nutzer.

Außerdem empfehle ich, jeden Schritt einzeln live zu schalten. Verschlechtert sich dann eine Kennzahl, erkennen Sie sofort, welche Änderung verantwortlich ist.

Wann brauchen Sie kein Lazy Loading?

Nicht jede Seite braucht es. Denken Sie an eine Kontaktseite mit einem einzigen Bildschirm, eine kurze Leistungsseite mit wenigen Bildern oder eine Landingpage, deren Inhalt fast komplett in den ersten Bildschirm passt. Hier gibt es kaum etwas zu verzögern, und das Risiko einer falschen Markierung steigt.

Ebenso klein ist der Gewinn bei kleinen Bildern, die Besucher fast sicher sehen. Icons im Menü oder ein Vertrauenssiegel direkt unter dem ersten Bildschirm sind gute Beispiele. Wer sie verzögert, zeigt manchmal nur kurz eine leere Fläche und gewinnt sonst nichts.

Meine Sicht ist deshalb klar: Betrachten Sie Lazy Loading als Werkzeug für lange, medienreiche Seiten und nicht als Standardregel. Anders gesagt lautet der richtige Ansatz „dort einsetzen, wo es hilft“ und nicht „überall einsetzen“.

Wer sollte im Team über Lazy Loading entscheiden?

Lazy Loading wirkt wie ein technischer Schalter, trotzdem würde ich die Entscheidung nicht einer einzelnen Person überlassen. Das Design weiß, welches Bild im ersten Bildschirm steht. Die Entwicklung verantwortet das Template, und die SEO Seite prüft, was Google tatsächlich sieht. Treffen diese drei Perspektiven nicht zusammen, kann die Verbesserung eines Teams die Kennzahl eines anderen verschlechtern.

In meiner Arbeitsweise definieren wir den ersten Bildschirm für jedes Template gemeinsam in der Designphase. Danach überträgt die Entwicklung diese Definition in den Code. Nach dem Launch prüfen wir das Ergebnis mit der Search Console und mit Felddaten. Wer das von Anfang an einplant, zahlt deutlich weniger als für eine spätere Korrektur. Deshalb spreche ich das Thema in jedem Webdesign Projekt früh an.

Zeigt eine bestehende Website gleichzeitig Probleme mit Lazy Loading, Infinite Scroll und Indexierung, sollten Sie diese als ein System betrachten. In solchen Fällen beginne ich im Rahmen der SEO Beratung mit einem Audit auf Templateebene. Die technischen Anforderungen der KI gestützten Suche beschreibe ich zudem im Beitrag technisches SEO nach der KI Wende.