Ist Ihre Website bereit für Google & KI?

Es misst, wie viel sichtbarer Text im Verhältnis zum gesamten HTML-Code einer Seite steht. Ein sehr niedriger Wert deutet auf aufgeblähten Code oder sehr wenig echten Inhalt hin — beides erschwert es Suchmaschinen, die Seite thematisch einzuordnen.

Ohne width/height reserviert der Browser keinen Platz für das Bild, bevor es geladen ist — der restliche Inhalt „springt“ beim Laden. Dieser Layout-Shift ist Teil der Core Web Vitals (CLS) und wirkt sich direkt auf Nutzererlebnis und Ranking aus.

Mit loading="lazy" werden Bilder erst geladen, wenn sie in den sichtbaren Bereich scrollen. Das verkürzt die initiale Ladezeit spürbar, besonders bei bildlastigen Seiten — ein direkter Vorteil für Geschwindigkeit und Core Web Vitals.

WebP und AVIF komprimieren Bilder bei gleicher visueller Qualität deutlich stärker als klassische JPG- oder PNG-Dateien. Das reduziert die Ladezeit spürbar — ein messbarer Vorteil für Performance-Rankingfaktoren.

Mixed Content bedeutet, dass eine über HTTPS verschlüsselte Seite Ressourcen (Bilder, Skripte) unverschlüsselt über HTTP nachlädt. Browser blockieren solche Inhalte teilweise oder markieren die Seite als unsicher — das untergräbt den eigentlichen Zweck von HTTPS.

Strict-Transport-Security zwingt den Browser, eine Seite ausschließlich über HTTPS zu laden — selbst wenn jemand versehentlich http:// eingibt. Er wird selten manuell auf Serverebene gesetzt und fehlt deshalb auch auf vielen Websites, die technisch längst auf HTTPS laufen.

Ohne Gzip- oder Brotli-Komprimierung überträgt der Server HTML, CSS und JS ungekürzt — oft deutlich mehr Datenvolumen als nötig. Viele Standard-Hosting-Setups aktivieren das nicht automatisch, wodurch dieser einfache Geschwindigkeitsgewinn regelmäßig ungenutzt bleibt.

Er verhindert, dass der Browser den Dateityp einer Ressource selbst „errät“ und dadurch z. B. eine hochgeladene Bilddatei versehentlich als Skript ausführt. Ein einfacher, aber häufig vergessener Sicherheits-Header.

Ohne rel="noopener" erhält die neu geöffnete Seite über window.opener Zugriff auf das ursprüngliche Tab und könnte es umleiten (Tabnabbing). Dieses Attribut wird bei externen Links in der Praxis auf sehr vielen Websites schlicht vergessen.

Jede zusätzliche Weiterleitung (z. B. http → https → www → finale URL) kostet Ladezeit und Crawling-Budget. Häufig entstehen solche Ketten über Jahre durch nachträglich ergänzte Regeln, ohne dass sie je bereinigt wurden.

Ohne Doctype rendern Browser die Seite im sogenannten Quirks-Modus mit inkonsistenten, veralteten Regeln für Layout und CSS. Bei älteren oder migrierten Websites fehlt diese erste Zeile überraschend oft.

Viele Templates befüllen Title und H1 automatisch mit demselben Text. Das verschenkt Potenzial: Der Title kann zusätzliche Keywords oder den Markennamen tragen, während die H1 nutzerorientiert und thematisch fokussiert bleibt.

Wenn ein CMS die Meta-Description automatisch aus dem Title generiert, entsteht eine inhaltslose Dopplung in den Suchergebnissen. Eine eigenständige Beschreibung erhöht die Klickwahrscheinlichkeit deutlich mehr.

Ein häufiger, schwer auffindbarer Fehler ist ein Canonical-Tag, der auf die falsche URL zeigt — etwa versehentlich immer auf die Startseite. Google indexiert dann im schlimmsten Fall die eigentliche Seite gar nicht, obwohl technisch ein Canonical gesetzt ist.

Eine 'Sitemap:'-Zeile in der robots.txt hilft Suchmaschinen-Crawlern, die Sitemap automatisch zu finden, ohne dass sie manuell in der Google Search Console eingereicht werden muss. Viele Websites haben beide Dateien, verknüpfen sie aber nicht.

Nach einem Relaunch oder Domain-Umzug bleibt der Favicon-Link im Code oft stehen, während die Datei selbst längst gelöscht oder verschoben wurde. Nur ein echter Abruf der Datei zeigt, ob sie wirklich noch existiert.

Ein og:image-Tag kann korrekt gesetzt sein und trotzdem auf eine gelöschte Bilddatei zeigen. Das Ergebnis: Ein leeres oder kaputtes Vorschaubild, sobald jemand den Link auf Social Media oder in Messengern teilt.

Über Jahre hinweg werden Unterseiten gelöscht oder URLs geändert, ohne dass interne Links darauf aktualisiert werden. Solche toten Links verschlechtern die Nutzererfahrung und verschwenden Crawling-Budget.

Ein <script>-Tag ohne async oder defer zwingt den Browser, das Skript vollständig zu laden und auszuführen, bevor er mit dem Rendering der restlichen Seite fortfährt. Das verzögert den ersten sichtbaren Inhalt spürbar.

Wenn CMS und SEO-Plugin unabhängig voneinander je einen Canonical-Tag setzen, erhält Google widersprüchliche Signale darüber, welche URL die bevorzugte Version ist — im Zweifel wird der Tag dann ganz ignoriert.

Sind beide Versionen ohne Weiterleitung erreichbar, sieht Google zwei identische Seiten unter unterschiedlichen URLs — Rankingsignale wie Backlinks verteilen sich dann auf zwei Adressen statt sich auf eine zu bündeln.

Sehr viele verschachtelte HTML-Elemente (oft durch Page-Builder oder viele Plugins verursacht) verlangsamen das Rendering und die Interaktivität der Seite spürbar, selbst wenn die Ladezeit der Datei selbst kurz ist.

Ohne zugehöriges <label> oder aria-label wissen Screenreader-Nutzer nicht, was in ein Feld eingetragen werden soll. Ein sehr häufiger, aber leicht behebbarer Barrierefreiheits-Fehler bei Kontaktformularen.

Fehlt der Header komplett, treffen Browser und CDNs eigene, unvorhersehbare Entscheidungen darüber, was wie lange zwischengespeichert wird. Eine bewusste Angabe — selbst 'no-cache' — ist immer besser als keine Angabe.

Eine Zeile 'User-agent: *' gefolgt von 'Disallow: /' schließt sämtliche Suchmaschinen-Crawler von der gesamten Website aus. Diese Regel stammt meist aus einer Staging-Umgebung und wird beim Go-Live versehentlich nicht entfernt.

Der X-Robots-Tag wird als HTTP-Header statt im HTML gesetzt, oft über Server- oder CDN-Konfiguration. Er kann eine Seite unbemerkt von der Indexierung ausschließen, selbst wenn der sichtbare Meta-Tag im Quellcode unauffällig ist.

Ein Soft-404 liegt vor, wenn eine nicht existierende Seite Status 200 statt 404 zurückgibt. Google erkennt solche Fehlerseiten oft trotzdem, verschwendet dabei aber Crawling-Budget, das besser für echte Inhalte genutzt würde.

Eine sitemap.xml kann technisch erreichbar sein, aber leer oder fehlerhaft formatiert sein — etwa durch einen abgebrochenen Exportprozess. Erst eine gültige XML-Struktur mit tatsächlichen URL-Einträgen ist für Suchmaschinen nutzbar.

Header wie 'Server: Apache/2.4.41' oder 'X-Powered-By: PHP/7.2' verraten Angreifern genau, nach welchen bekannten Schwachstellen sie für diese Version suchen müssen. Ein einfacher, aber oft übersehener Sicherheits-Fehler.

user-scalable=no oder maximum-scale=1 im Viewport-Tag verhindert, dass sehbehinderte Nutzer Inhalte per Fingergeste vergrößern können. Google bewertet das inzwischen als Barrierefreiheits- und Nutzererfahrungs-Problem.

llms.txt ist ein neuer, noch wenig verbreiteter Standard, der KI-Systemen wie ChatGPT oder Perplexity in einfacher Textform erklärt, worum es auf einer Website geht. Da er erst seit Kurzem existiert, hat ihn bislang kaum eine Website umgesetzt.

Als Base64-Daten-URI eingebettete Bilder vergrößern die HTML-Datei selbst erheblich und können vom Browser nicht separat zwischengespeichert werden — im Gegensatz zu normal eingebundenen Bilddateien.

Ohne srcset lädt jedes Gerät dieselbe, oft für Desktop-Bildschirme optimierte Bildgröße — auch ein Smartphone. Das verschwendet Datenvolumen und Ladezeit unnötig, besonders bei mobiler Nutzung.

Eine CSP schränkt ein, von welchen Quellen Skripte, Styles und andere Ressourcen geladen werden dürfen. Sie ist eine der wirksamsten Verteidigungen gegen Cross-Site-Scripting, wird aber auf den meisten Websites nie konfiguriert.

Sie legt fest, welche Browser-Funktionen (Kamera, Mikrofon, Standort) auf einer Seite überhaupt genutzt werden dürfen — auch von eingebetteten Drittanbieter-Skripten. Fast keine Website setzt diesen Header bewusst.

Sie steuert, wie viele URL-Informationen beim Klick auf einen externen Link an die Zielseite weitergegeben werden. Ohne explizite Angabe überlassen Websites dieses Verhalten dem jeweiligen Browser-Standard.

Er verhindert, dass eine fremde Website die eigene Seite unsichtbar in einem iframe einbettet, um Nutzer zu Klicks auf verdeckte Inhalte zu verleiten (Clickjacking).

Unter /.well-known/security.txt hinterlegt, gibt sie Sicherheitsforschern eine klare, offizielle Anlaufstelle, um Schwachstellen verantwortungsvoll zu melden. Ein moderner Standard, den bislang kaum eine Website umsetzt.

Ohne Secure-Flag könnten Cookies theoretisch auch über eine unverschlüsselte HTTP-Verbindung übertragen werden. Das Flag stellt sicher, dass sie ausschließlich über HTTPS gesendet werden.

Access-Control-Allow-Origin: '*' erlaubt jeder beliebigen fremden Website, die Antwort der eigenen Seite per Skript auszulesen. Für normale HTML-Seiten ist das selten beabsichtigt.

Es färbt die Browser-Oberfläche (z. B. die Adressleiste auf Android) passend zur Markenfarbe ein — ein kleines, aber häufig übersehenes Detail für einen konsistenten Markenauftritt.

Legt ein Nutzer die Seite auf dem iOS-Homescreen ab, zeigt Apple ohne dieses Icon oft nur einen unscharfen Screenshot der Seite statt eines sauberen Icons.

Es beschreibt Name, Icons und Darstellung der Website, damit sie als installierbare Progressive Web App erkannt wird. Ohne Manifest bleibt dieser Weg zur App-artigen Nutzung verschlossen.

Google ignoriert das keywords-Tag seit über einem Jahrzehnt vollständig. Ist es trotzdem vorhanden, deutet das meist auf veraltete SEO-Praktiken hin, die auch anderswo auf der Seite zu erwarten sind.

Sie weist Google an, in den Suchergebnissen keinen Textausschnitt zur Seite anzuzeigen. Ist sie versehentlich gesetzt, wirkt der Suchtreffer deutlich weniger einladend und die Klickrate sinkt.

Viele Websites setzen JSON-LD nur für einzelne Elemente wie Bewertungssterne, ohne die Website selbst als Organization oder WebSite zu definieren — genau das ist aber die Grundlage dafür, dass KI-Systeme die Entität dahinter verstehen.

Es lässt Google in den Suchergebnissen eine Navigationsspur statt der reinen URL anzeigen — das wirkt aufgeräumter und erhöht nachweislich die Klickrate, wird aber von den wenigsten Websites umgesetzt.

sameAs verknüpft die eigene Website mit offiziellen Profilen auf Social Media oder in Verzeichnissen. Für KI-Systeme ist das ein starkes Signal, um die Entität eindeutig zu identifizieren — in der Praxis wird es kaum genutzt.

Sehr lange, verschachtelte Sätze sind für Menschen schwerer zu lesen und erschweren es KI-Systemen, einzelne Aussagen sauber zu extrahieren. Kürzere Sätze werden zuverlässiger korrekt verstanden.

Eine ungewöhnlich hohe Zahl externer Links auf einer einzelnen Seite kann wie ein Linkverzeichnis wirken und verwässert die Rankingsignale, die eigentlich der eigenen Seite zugutekommen sollten.

Häufig setzen sowohl das CMS als auch ein zusätzliches SEO-Plugin unabhängig voneinander je eine Meta-Description. Suchmaschinen verwenden dann nur eine davon — welche, ist nicht immer vorhersehbar.

Browser und Suchmaschinen verwenden nur das erste gefundene <title>-Tag. Ein zweites ist meist ein Überbleibsel aus einem Template-Fehler und sollte entfernt werden.

Im Gegensatz zu einer echten serverseitigen 301-Weiterleitung gibt ein Meta-Refresh kaum Linkkraft an die Zielseite weiter und wird von Suchmaschinen inkonsistent interpretiert.

Google interpretiert einen Bindestrich als Trennzeichen zwischen zwei Wörtern, einen Unterstrich dagegen nicht. 'blaue_lederjacke' wird also anders verarbeitet als 'blaue-lederjacke'.

Auf manchen Servern werden /Seite und /seite als zwei unterschiedliche, eigenständige URLs behandelt. Das erzeugt unbeabsichtigten doppelten Inhalt, den durchgängige Kleinschreibung von vornherein vermeidet.

Sehr lange URLs werden in Suchergebnissen abgeschnitten dargestellt und sind schwerer zu merken, zu teilen oder korrekt abzutippen als kurze, sprechende Adressen.

Setzt der Server einen Content-Language-Header, der vom lang-Attribut im HTML abweicht, erhalten Suchmaschinen widersprüchliche Signale darüber, in welcher Sprache die Seite tatsächlich verfasst ist.

rel="nofollow" wurde für nicht vertrauenswürdige externe Links entwickelt. Wird es versehentlich auf interne Navigation angewendet, verhindert das, dass Linkkraft innerhalb der eigenen Website weitergegeben wird.

Eine sehr kurze H1 wirkt unspezifisch, eine sehr lange verwässert den thematischen Fokus. Ein Rahmen von etwa 10 bis 70 Zeichen bietet meist genug Raum für eine klare, aussagekräftige Überschrift.

Links mit href="javascript:..." statt einer echten URL sind für Suchmaschinen-Crawler nicht nachvollziehbar und für Screenreader-Nutzer oft nicht bedienbar. Ein <button> ist hierfür meist die richtige Wahl.

Jedes verlinkte Stylesheet blockiert das Rendering, bis es geladen ist. Viele einzelne CSS-Dateien statt eines gebündelten Pakets verzögern dadurch den ersten sichtbaren Inhalt der Seite spürbar.

Jede zusätzliche Domain (Tracking, Chat-Widgets, Werbenetzwerke) erfordert eine eigene DNS-Auflösung und Verbindung. Websites mit vielen verschiedenen Drittanbietern laden dadurch spürbar langsamer.

Wird loading="lazy" pauschal auf alle Bilder angewendet, verzögert das ausgerechnet das meist sofort sichtbare erste Bild — und damit den Largest Contentful Paint, eine der wichtigsten Core-Web-Vitals-Kennzahlen.

Ein einzelnes, unkomprimiertes Bild kann mehrere Megabyte groß sein und dominiert dann die gesamte Ladezeit der Seite — unabhängig davon, wie schlank der restliche Code ist.

Aufgeblähtes Markup, große Inline-Datenmengen oder unnötig verschachtelte Wrapper-Elemente vergrößern die HTML-Datei — der Browser muss dadurch mehr Daten laden und verarbeiten, bevor überhaupt etwas sichtbar wird.

Sehr große <style>-Blöcke direkt im HTML werden bei jedem Seitenaufruf erneut übertragen, statt wie eine externe CSS-Datei vom Browser zwischengespeichert zu werden.

Es markiert eindeutig den Hauptinhalt der Seite und hilft Screenreadern sowie Suchmaschinen, diesen von Navigation, Sidebar und Footer zu unterscheiden. Auf vielen älteren Websites fehlt es komplett.

Werden Navigation, Kopf- und Fußbereich nur mit generischen <div>-Elementen statt <header>, <nav> und <footer> umgesetzt, verlieren Screenreader und Suchmaschinen wichtige strukturelle Orientierungspunkte.

In Deutschland ist ein Impressum nach §5 TMG für nahezu jede geschäftliche Website gesetzlich vorgeschrieben. Es fehlt überraschend oft oder ist so gut versteckt, dass es kaum auffindbar ist.

Die DSGVO verlangt von praktisch jeder Website in der EU eine leicht auffindbare Datenschutzerklärung. Gerade bei kleineren oder schnell erstellten Websites fehlt dieser Link häufig oder ist schwer zu finden.

Ein Dateiname wie 'blaue-lederjacke.jpg' liefert zusätzlichen thematischen Kontext für die Google-Bildersuche. Direkt von der Kamera oder dem Smartphone hochgeladene Dateien wie 'IMG_2481.jpg' verschenken dieses Potenzial vollständig.

Es legt die kanonische URL für geteilte Links fest. Ohne dieses Tag kann eine Seite mit angehängten Tracking-Parametern beim Teilen fälschlich als eigenständige, neue Seite gezählt werden.

Enthält es eine konkrete Versionsnummer (z. B. 'WordPress 5.4'), wissen Angreifer sofort, nach welchen bekannten Schwachstellen dieser spezifischen Version sie gezielt suchen können.

Die kanonische URL sollte immer die 'sauberste' Version der Seite sein. Enthält sie versehentlich UTM- oder Sitzungsparameter, wird genau diese unerwünschte Variante als bevorzugte Version signalisiert.

Zeigt der Canonical-Link auf eine http-Version, während die Seite selbst über https läuft, entsteht ein Widerspruch, der im schlimmsten Fall dazu führt, dass Google die unsichere Version bevorzugt.

Ein Viewport-Tag mit einer festen Pixelbreite (z. B. width=980) statt width=device-width lässt die Seite auf Mobilgeräten weiterhin wie eine verkleinerte Desktop-Version aussehen.

Bei der Tiefenanalyse (bis zu 100 Seiten) wird zusätzlich geprüft, ob mehrere Seiten identische Title-Tags verwenden — das verwässert Rankingsignale und verwirrt Google bei der Auswahl der passenden Seite für eine Suchanfrage.

Identische Meta-Descriptions auf mehreren Seiten sind ein häufiges Templating-Problem und wirken in den Suchergebnissen wie Duplicate Content — jede Seite sollte ihre eigene, spezifische Beschreibung haben.

Eine Seite, auf die von keiner anderen gecrawlten Seite ein interner Link verweist. Ohne internen Link finden weder Nutzer noch Google diese Seite zuverlässig — auch wenn sie in der Sitemap steht.

Die Tiefenanalyse ruft die in der sitemap.xml gelisteten URLs tatsächlich ab, statt nur die Datei selbst zu prüfen — so werden tote Links in der Sitemap gefunden, die sonst unbemerkt Crawling-Budget verschwenden.

Über interne Links erreichbare Seiten, die aber nicht in der sitemap.xml gelistet sind, werden von Suchmaschinen möglicherweise langsamer oder gar nicht gefunden.

Statt nur eine Stichprobe auf einer Seite zu prüfen, aggregiert die Tiefenanalyse dieses Ergebnis über alle gecrawlten Seiten und zeigt, wie viele Seiten insgesamt betroffen sind.

Seiten, die erst nach mehr als 3 Klicks von der Startseite aus erreichbar sind, werden von Google tendenziell als weniger wichtig eingestuft und seltener gecrawlt.

Ein Organization/WebSite-Schema, das nur auf der Startseite vorhanden ist, hilft KI-Systemen weniger als ein konsistent über die Website verteiltes Schema — die Tiefenanalyse zeigt, auf wie vielen Seiten es fehlt.

Ein fehlender MX-Eintrag ist ein subtiles, aber häufig übersehenes Vertrauenssignal — besonders bei B2B-Domains wirkt es unfertig, wenn die eigene Domain keine E-Mails empfangen kann.

SPF (Sender Policy Framework) legt fest, welche Server im Namen der Domain E-Mails versenden dürfen. Ohne SPF können Angreifer leichter gefälschte E-Mails im Namen der eigenen Domain versenden (Spoofing).

DMARC legt fest, was mit E-Mails passieren soll, die den SPF/DKIM-Check nicht bestehen, und ermöglicht Berichte über Missbrauchsversuche der eigenen Domain.

Ein CAA-Eintrag schränkt ein, welche Zertifizierungsstellen SSL-Zertifikate für die Domain ausstellen dürfen — reduziert das Risiko, dass ein kompromittierter Drittanbieter unautorisiert ein Zertifikat für die Domain ausstellt.

Viele Mobilfunknetze bevorzugen IPv6. Ohne AAAA-Eintrag läuft der Traffic dieser Nutzer über einen Umweg (NAT64), was die Ladezeit geringfügig verschlechtern kann.

Ein abgelaufenes SSL-Zertifikat macht eine Website in allen modernen Browsern sofort als 'nicht sicher' unzugänglich — ein rechtzeitiger Hinweis vor Ablauf verhindert diesen kompletten Ausfall.

Vergessener Platzhaltertext aus der Entwicklungsphase (typische Fuelltext-Floskeln oder Hinweise wie 'in Kuerze verfuegbar') wirkt unfertig und ist ein häufiges Anzeichen für nicht abgeschlossene Seiten, die versehentlich live gegangen sind.

Ein Footer mit einem mehrere Jahre alten Copyright-Jahr signalisiert Besuchern (bewusst oder unbewusst), dass die Website länger nicht gepflegt wurde — ein kleines, aber leicht behebbares Vertrauenssignal.

Ein <track kind="captions">-Element liefert Untertitel für Video-/Audio-Inhalte — wichtig für Barrierefreiheit und wird von Google teils zur Texterschließung von Videoinhalten genutzt.

Attribute wie autocomplete="email" oder autocomplete="tel" lassen Browser Formularfelder automatisch vorausfüllen — das senkt die Absprungrate bei Kontakt- und Anfrageformularen spürbar.

Ein versteckter 'Zum Inhalt springen'-Link als erstes fokussierbares Element ermöglicht es Tastatur- und Screenreader-Nutzern, die Hauptnavigation zu überspringen und direkt zum Inhalt zu gelangen.

<th>-Elemente kennzeichnen Kopfzeilen semantisch korrekt — ohne sie können Screenreader Datenzellen nicht eindeutig der zugehörigen Spalten-/Zeilenüberschrift zuordnen.

Doppelte IDs sind ungültiges HTML und machen Ankerlinks, Formular-Labels und aria-Referenzen unzuverlässig, weil der Browser nicht eindeutig weiß, welches Element gemeint ist.

Wird ein einzelnes Wort auffällig häufig im Verhältnis zum restlichen Text wiederholt, wirkt das für Google wie eine künstliche Manipulation statt natürlicher Sprache und kann der Seite schaden.

Google schneidet Titles nach Pixelbreite ab, nicht nach Zeichenzahl — ein Title mit vielen breiten Zeichen (Großbuchstaben, 'm'/'w') kann trotz passender Zeichenzahl in den Suchergebnissen abgeschnitten werden.

Wie beim Title zählt in den Suchergebnissen die tatsächliche Darstellungsbreite, nicht die Zeichenanzahl — bei vielen breiten Zeichen kann die Description vorzeitig mit '...' abgeschnitten werden.

Eine Zwischenüberschrift soll einen Abschnitt prägnant zusammenfassen — wird sie zu einem ganzen Satz mit Nebeninformationen, verliert sie ihre Funktion als schnelle Orientierungshilfe.

Besteht ein sehr hoher Anteil des Fließtexts nur aus Linktext, wirkt die Seite für Google eher wie ein Linkverzeichnis als wie eigenständiger, hochwertiger Inhalt.

Meta-Tags gehören ausschließlich in den <head> — im <body> platzierte meta-Tags werden von vielen Browsern und Crawlern schlicht ignoriert und haben keinerlei Wirkung.

Fehlt 'text/html' im Content-Type-Header oder ist er falsch gesetzt, können Browser oder Crawler die Seite falsch interpretieren, statt sie korrekt als HTML-Dokument zu rendern.

Ein <link rel="preload" as="image"> für das Largest-Contentful-Paint-Bild beschleunigt dessen Ladebeginn spürbar — LCP ist einer der drei zentralen Core-Web-Vitals-Werte.

Damit wird die DNS-Auflösung und der Verbindungsaufbau zu wichtigen Drittanbieter-Domains (Tracking, Fonts, Widgets) schon vorab angestoßen, statt erst zu warten, bis die Ressource tatsächlich gebraucht wird.

Ohne preload lädt der Browser Schriftdateien oft erst spät nach — das erzeugt einen kurzen unsichtbaren Text (Flash of Invisible Text) und einen Layout-Sprung, sobald die Schrift eintrifft.

Unminifiziertes Inline-CSS mit vielen Zeilenumbrüchen und Einrückungen wird bei jedem Seitenaufruf ungekürzt mit dem HTML übertragen und vergrößert die Ladezeit unnötig.

Unminifizierter Inline-Code wird bei jedem Seitenaufruf erneut in voller Größe übertragen, statt wie eine externe, gebündelte Datei vom Build-Prozess komprimiert und vom Browser gecacht zu werden.

Sehr große Mengen an Inline-JavaScript vergrößern die HTML-Datei selbst erheblich und können — anders als externe Skripte — vom Browser nicht separat zwischengespeichert werden.

Ein <video>-Element (autoplay, muted, loop) erzeugt bei gleicher Optik oft deutlich kleinere Dateien als ein animiertes GIF und ist damit deutlich ladezeitfreundlicher.

Er kündigt dem Client an, dass der Server HTTP/3 (QUIC) unterstützt — das beschleunigt vor allem den Verbindungsaufbau in mobilen oder instabilen Netzwerken.

Verweist ein Sprungmarken-Link auf ein id/name, das auf der Seite gar nicht existiert, scrollt der Klick für Nutzer ins Leere, statt zum gewünschten Abschnitt zu springen.

Sehr viele Links auf einer einzelnen Seite verwässern die weitergegebene Linkkraft pro Ziel und erschweren Nutzern die Orientierung im Inhalt.

Links auf localhost oder 127.0.0.1 sind meist ein vergessener Entwicklungsverweis aus der lokalen Umgebung — für Website-Besucher funktionieren sie nie.

Ein file://-Link verweist auf einen Pfad auf der Festplatte des Erstellers und funktioniert ausschließlich dort — für jeden anderen Besucher ist er automatisch defekt.

Suchmaschinen-Crawler und Nutzer ohne JavaScript können einer onclick-basierten Navigation nicht folgen — ein echtes href-Ziel auf einem <a>-Element ist immer zugänglich.

Meist durch einen Encoding-Fehler bei der URL-Erzeugung — ein Leerzeichen im Link-Ziel sollte korrekt als %20 kodiert oder ganz entfernt werden, sonst kann das Ziel unzuverlässig aufgerufen werden.

Ein Link von einer sicheren auf eine unsichere Zielseite erzeugt beim Klick eine unnötige Downgrade-Warnung oder Weiterleitung — verlinkte Ziele sollten wo möglich direkt auf HTTPS zeigen.

Ein tel:-Link ohne gültiges Nummernformat oder ein mailto:-Link ohne valide E-Mail-Adresse öffnet beim Klick keine funktionierende Anruf- oder Mail-App — ein oft übersehener Detailfehler.

Sehr tief verschachtelte URL-Pfade (viele /Ebenen/) erhalten tendenziell weniger Linkkraft und werden von Suchmaschinen seltener und weniger gründlich gecrawlt.

Bilder mit einer Breite oder Höhe von über 2000px sind für die allermeisten Anzeigekontexte überdimensioniert und vergrößern die Ladezeit unnötig, ohne einen sichtbaren Qualitätsgewinn zu bringen.

Generische Alt-Texte wie 'Bild', 'Foto' oder der reine Dateiname liefern weder Screenreader-Nutzern noch der Google-Bildersuche einen echten inhaltlichen Mehrwert.

Screenreader lesen den kompletten Alt-Text vor — ein Wert über etwa 125 Zeichen wird unhandlich und sollte auf eine prägnante Beschreibung des Bildinhalts gekürzt werden.

Eine <figcaption> liefert zusätzlichen, semantisch korrekt zugeordneten Kontext zu einem Bild oder Diagramm — sowohl für Nutzer als auch für Suchmaschinen.

Sehr detailreiche Inline-SVGs vergrößern die HTML-Datei erheblich und werden dabei — anders als eine externe .svg-Datei — bei jedem Seitenaufruf erneut übertragen statt gecacht.

Ohne ein abschließendes <img>-Element innerhalb von <picture> zeigen ältere Browser, die das Element nicht unterstützen, gar kein Bild an.

Als CSS-Hintergrundbild eingebundene Inhalte werden von Suchmaschinen für die Bilder-SEO ignoriert und haben keinen Alt-Text — ein echtes <img>-Element ist hier immer die bessere Wahl.

Ein reiner Icon-Button ganz ohne Beschriftung ist für Screenreader-Nutzer nicht greifbar — mindestens eines der drei Signale muss vorhanden sein, damit die Funktion erkennbar bleibt.

Screenreader-Nutzer springen oft über eine isolierte Liste aller Linktexte einer Seite — generische Formulierungen wie 'hier' sind dort ohne umgebenden Kontext bedeutungslos.

Wird der Standard-Fokusring per CSS entfernt, ohne ihn durch eine eigene Kennzeichnung (z. B. :focus-visible mit box-shadow) zu ersetzen, können Tastatur-Nutzer nicht mehr erkennen, welches Element gerade fokussiert ist.

Eine verlinkte Über-uns-Seite mit Team, Erfahrung und Hintergrund gibt Nutzern und Google konkrete Anhaltspunkte zur Vertrauenswürdigkeit der dahinterstehenden Organisation.

Bietet eine Website Verträge, Bestellungen oder Abonnements an, sollten Nutzungsbedingungen klar verlinkt sein — fehlen sie, wirkt das Angebot rechtlich und für Nutzer weniger seriös.

Eine klar erreichbare Kontaktmöglichkeit fehlt überraschend oft — ohne sie wirkt eine Website für Nutzer und Google weniger vertrauenswürdig und schwerer greifbar.

Bei Blogartikeln oder News zeigt ein <time>-Element oder datePublished/dateModified im Schema die Aktualität des Inhalts — besonders wichtig bei Themen, die sich schnell ändern.

Eine sichtbare oder im Schema als author hinterlegte Autoren-Angabe untermauert Expertise und Vertrauenswürdigkeit redaktioneller Inhalte — ein zentrales E-E-A-T-Kriterium.

Eine im Footer sichtbare und/oder im Organization/LocalBusiness-Schema hinterlegte Adresse ist ein starkes lokales Vertrauens- und E-E-A-T-Signal, das rein digitale Angebote oft vermissen lassen.

Verweise auf vertrauenswürdige externe Quellen bei Aussagen, Statistiken oder Fakten zeigen, dass Behauptungen belegt statt frei erfunden sind — ein klassisches E-E-A-T-Signal.

Bei Seiten mit echten, häufig gestellten Fragen ermöglicht ein FAQPage-Schema erweiterte Suchergebnisse (Rich Results) mit direkt aufklappbaren Fragen in Google.

Enthält das FAQPage-Schema Fragen oder Antworten, die im sichtbaren Seiteninhalt gar nicht (mehr) vorkommen, kann Google das Rich-Result-Snippet ablehnen oder komplett abwerten.

Hat die og:image-URL weder eine erkennbare Dateiendung noch ein og:image:type-Tag, können manche Plattformen das Format nicht sicher bestimmen und zeigen kein Vorschaubild an.

Weichen sie voneinander ab, können Social-Media-Shares und Suchmaschinen leicht unterschiedliche URLs derselben Seite fälschlich als zwei eigenständige Seiten behandeln.

Bei redaktionellen Inhalten (Blog, Ratgeber) senken sichtbare Share-Buttons die Hürde für organische Weiterverbreitung über soziale Netzwerke spürbar.

Segmente, die nur aus Wörtern wie 'und', 'oder' oder 'der' bestehen, tragen nichts zur thematischen Klarheit der URL bei und verlängern sie unnötig.

Meist durch fehlerhafte Link-Konkatenation im Code — doppelte Slashes können dazu führen, dass dieselbe Seite unter mehreren eigenständig indexierten URL-Varianten erscheint.

Sie werden von Nutzern seltener korrekt kopiert und geteilt als eine saubere, mit Bindestrichen getrennte URL, und deuten oft auf eine automatisch generierte, ungepflegte Adresse hin.

Nicht alle Systeme und Social-Media-Plattformen verarbeiten rohe Nicht-ASCII-Zeichen in URLs zuverlässig — Umlaute sollten entweder vermieden oder korrekt prozent-kodiert werden.

Das deutet fast immer auf einen Routing- oder Link-Fehler im Code hin und sollte entfernt werden, statt als eigenständige, verwirrende URL bestehen zu bleiben.

utm_*, gclid oder fbclid gehören ausschließlich in ausgehende Kampagnen-Links — landen sie in der intern verlinkten oder kanonischen URL, entstehen unnötig viele URL-Varianten derselben Seite.

Parameter wie PHPSESSID oder JSESSIONID erzeugen für jeden Besucher eine eigene, duplizierte URL und können bei versehentlicher Weitergabe (URL-Leak) fremden Zugriff auf die Sitzung ermöglichen.

Seiten wie /suche/?q=... bieten meist keinen eigenständigen Mehrwert für die Google-Suche und sollten per robots-Meta-Tag oder robots.txt ausgeschlossen werden, um Crawl-Budget zu sparen.

Browser verwenden nur das erste gefundene <meta name="viewport">-Tag — ein zweites ist meist ein Template-Fehler und sollte entfernt werden.

Solche Texte sind auf mobilen Geräten kaum lesbar — Google berücksichtigt zu kleine Schriftgrößen inzwischen als Signal für schlechte mobile Nutzerfreundlichkeit.

Mehrere <head>-Elemente sind ungültiges HTML und führen zu unvorhersehbarem Verhalten je nach Browser — pro Dokument darf es nur genau eines geben.

<noscript> ist im <head> nur gültig, wenn es ausschließlich link/style/meta-Elemente enthält (z. B. als Fallback für asynchron geladene Stylesheets) — enthält es Text oder andere Elemente, gehört dieser Inhalt in den <body>.

Nur title, meta, link, style, script, base und noscript sind im <head> zulässig — sichtbare Inhaltselemente wie div, p oder img gehören ausschließlich in den <body>.

window.location- oder location.replace-Weiterleitungen werden von Suchmaschinen inkonsistent und verzögert verarbeitet — eine echte serverseitige 301/302-Weiterleitung ist immer zuverlässiger.

Funktional identisch, aber auf HTTP-Header-Ebene statt im HTML gesetzt — auch hier ist eine echte 301-Weiterleitung die sauberere und für SEO vorteilhaftere Lösung.

Werden GPTBot, Google-Extended, PerplexityBot oder ähnliche KI-Crawler ausgesperrt, können ChatGPT, Gemini oder Perplexity die Inhalte der Website gar nicht erst erfassen — kritisch für GEO/AEO-Sichtbarkeit.

Ein <link rel="llms.txt"> im <head> macht die Datei auch für Tools auffindbar, die nur die aufgerufene Seite analysieren, statt proaktiv nach /llms.txt zu suchen.

Google ignoriert Hreflang-Angaben auf einer als noindex markierten Seite vollständig — die Kombination signalisiert widersprüchliche Absichten und sollte vermieden werden.

Fehlt der Selbstverweis, gilt die gesamte Hreflang-Gruppe für Google als fehlerhaft und wird ignoriert — jede Sprachversion muss sich selbst als eines der Ziele nennen.

LCP misst, wie lange es dauert, bis das größte sichtbare Element (meist Hero-Bild oder Überschrift) gerendert ist — nur in einem echten Browser mit Netzwerk-/CPU-Drosselung messbar, nicht durch reines HTML-Auslesen. Google wertet unter 2,5 Sekunden als gut.

CLS misst, wie stark sich sichtbare Inhalte nach dem ersten Rendern noch verschieben (z. B. durch nachladende Bilder ohne reservierten Platz) — ein Wert unter 0,1 gilt als gut und wird per echter Browser-Messung erfasst.

TBT summiert, wie lange lange JavaScript-Aufgaben den Hauptthread zwischen dem ersten Rendern und der vollen Interaktivität blockieren — je niedriger, desto schneller reagiert die Seite auf Klicks und Eingaben.

Eine kleine JavaScript-Datei kann trotzdem viel Rechenzeit auf dem Hauptthread beanspruchen (z. B. durch aufwendige Animationen) — die echte Auslastungszeit im Browser zeigt das, was eine reine Dateigrößen-Prüfung nicht erfassen kann.

Parse-, Kompilier- und Ausführungszeit von JavaScript verzögern die Interaktivität einer Seite direkt — diese Messung erfolgt in einem echten, gedrosselten Chromium-Browser, um realistische Werte zu liefern.

Über die Code-Coverage-Funktion des Browsers wird gemessen, welcher Anteil des geladenen JavaScripts beim ersten Laden der Seite tatsächlich ausgeführt wird — ein hoher ungenutzter Anteil deutet auf unnötig große Bundles hin.

Kontrast hängt von tatsächlich berechneten Farben (inkl. CSS, Overlays, Transparenz) ab, die sich erst nach dem Rendern im Browser bestimmen lassen — die Prüfung nutzt axe-core, dieselbe Engine, auf der auch Google Lighthouse basiert.

Er ist der Name, den ein Screenreader für Buttons, Links oder Dialoge tatsächlich ansagt — berechnet aus Text, aria-label und ARIA-Beziehungen im gerenderten DOM. Fehlt er (z. B. bei einem Dialog ohne aria-label), ist das Element für Screenreader-Nutzer unbenannt und funktionslos.

Nutzer klicken auf sichtbare Links, nicht auf unsichtbare JSON-LD-Daten — ein echter, sichtbarer Link zu Facebook, Instagram, LinkedIn & Co. (z. B. im Footer) stärkt zusätzlich Vertrauen und Entitäts-Signale für Google und KI-Systeme.

Wer bezahlte Werbung (Google Ads, Meta Ads etc.) schaltet oder plant, braucht ein passendes Tracking-Pixel, um Conversions zu messen und Zielgruppen fürs Retargeting aufzubauen — ohne Pixel verpufft ein Großteil des Kampagnen-Datenwerts ungenutzt.