Technik: Wie sauber liefert dein Server aus?

Technik-Befunde klingen nach Entwicklerthema, sind aber die Voraussetzung für alles andere. Ein guter Text auf einer Seite, die mit einem Fehler antwortet, ist kein guter Text — er ist nicht vorhanden. Deshalb steht diese Kategorie im Bericht ganz vorn, und deshalb sind die Lösungen hier oft kürzer, als man denkt: eine Serverzeile, eine Template-Änderung, ein korrigierter Link im Menü.

Wichtig zum Verständnis: Der Check ruft deine Seiten so ab, wie ein einfacher Crawler es tut. Er liest das HTML, das dein Server schickt, und führt kein JavaScript aus. Das ist keine Schwäche, sondern Absicht — es zeigt dir, was bei Crawlern ankommt, die nicht rendern.

Kein HTTPS: Der Browser warnt, bevor jemand deinen Text liest

Was das heißt

Der Check ruft deine Startseite ab und prüft, ob die Verbindung verschlüsselt ist. Steht im Ergebnis „Kein HTTPS“ mit dem Satz „Die Seite wird ohne Verschlüsselung ausgeliefert“, dann läuft deine Website über http statt über https. Der Befund ist rot und kostet fünf Punkte im Score.

Warum es zählt

Ohne Verschlüsselung kann jeder auf dem Weg zwischen Besucher und Server mitlesen und den Inhalt verändern: Werbung einbauen, Formulareingaben abgreifen. Browser schreiben bei solchen Seiten „Nicht sicher“ in die Adressleiste — bei einem Kontaktformular oder einem Warenkorb ist das Gespräch damit beendet. web.dev formuliert es ohne Ausnahme: Du solltest alle deine Websites mit HTTPS schützen, auch wenn sie keine sensiblen Daten übertragen. Dazu kommt ein Nebeneffekt: Wenn beide Varianten erreichbar sind, existiert dieselbe Seite doppelt, und Google muss raten, welche gilt.

So behebst du es

Zertifikat einrichten und alles dauerhaft per 301 auf https umleiten. Bei Shopify ist HTTPS eingebaut. Bei Shopware, WordPress und JTL-Shop holst du das Zertifikat beim Hoster — meist Let's Encrypt, ein Klick — und stellst danach die Adresse im System um: in Shopware am Verkaufskanal, in WordPress bei WordPress- und Website-Adresse, in JTL-Shop die SSL-Einstellung auf die komplette Seite. Danach prüfen, ob interne Links, Bilder und Canonical-Angaben ebenfalls auf https zeigen.

Quelle

web.dev: „Why HTTPS matters“ — „Always protect all your websites with HTTPS, even if they don't handle sensitive communications.“ Abgerufen 23.09.2026.

Seiten antworten mit einem Fehler: Google nimmt sie aus dem Index

Was das heißt

Der Check ruft deine Startseite und die von dort verlinkten Seiten ab und notiert, mit welchem Statuscode der Server antwortet. Im Ergebnis steht dann „X von Y Seiten antworten mit einem Fehler“, darunter die betroffenen Adressen samt Code. 404 heißt: nicht gefunden. 500 oder 503: der Server selbst hat ein Problem.

Warum es zählt

Google dokumentiert das ohne Interpretationsspielraum. Bei 4xx-Codes wird eine bereits indexierte URL aus dem Index entfernt, und neu gefundene 404-Seiten werden nicht verarbeitet. Bei 5xx-Codes bleiben indexierte URLs zunächst im Index, werden aber irgendwann verworfen — und hier kommt noch etwas dazu: Google senkt die Crawl-Rate für die ganze Website, proportional zur Zahl der fehlerhaften Adressen. Für KI-Antworten hängt alles daran: Laut Googles Leitfaden muss eine Seite indexiert und für ein Snippet zugelassen sein, um in AI Overviews oder im AI Mode erscheinen zu können.

So behebst du es

Je Adresse entscheiden: Seite wiederherstellen, per 301 auf den passenden Nachfolger umleiten, oder den internen Link entfernen. Ein 5xx ist keine SEO-Aufgabe, sondern ein Ticket an Hoster oder Entwicklung. Danach in der Google Search Console unter „Seitenindexierung“ nachsehen, ob Google dieselben Adressen kennt — dort steht der Bestand, der Check zeigt nur die Stichprobe. Welche Adressen der Googlebot tatsächlich abruft und welche Codes er dabei bekommt, steht nur in deinen Logs: Logfile-Analyse für SEO.

Quelle

Google Search Central: „How HTTP status codes affect Google's crawlers“ — „Google doesn't index URLs that return a 4xx status code, and URLs that are already indexed and return a 4xx status code are removed from the index“; zu 5xx: „Google's indexing pipeline removes from the index URLs that persistently return a server error.“ Abgerufen 23.09.2026. Zur Voraussetzung für KI-Antworten: Google: „Optimizing your website for generative AI features on Google Search“ — „a page must be indexed and eligible to be shown in Google Search with a snippet, fulfilling the Search technical requirements“. Abgerufen 23.09.2026.

Tote interne Links: Besucher und Crawler landen in der Sackgasse

Was das heißt

Neben den Seiten selbst prüft der Check eine Stichprobe der internen Links, die auf diesen Seiten stehen. Meldet das Ergebnis „X von Y geprüften internen Links sind tot“, dann zeigt jeder dieser Links auf eine Adresse, die nicht ausgeliefert wird. Zu jedem Treffer siehst du das Ziel, den Statuscode und die Seite, von der aus verlinkt wird. Die Stichprobe zeigt das Verhältnis, nicht die Gesamtzahl.

Warum es zählt

Ein toter Link kostet zweimal. Der Besucher landet auf einer Fehlerseite und geht meist zurück zu Google. Und der Crawler folgt dem Link, bekommt einen 4xx und verwendet den Inhalt nicht — die interne Verlinkung, mit der du eine Seite stärken wolltest, endet im Nichts. Wenn viele Links auf dasselbe verschwundene Ziel zeigen, ist das kein Einzelfall, sondern ein Template: Menü, Footer oder ein Baustein, der überall eingebunden ist.

So behebst du es

Erst das Muster suchen, dann an der Quelle korrigieren. Existiert das Ziel unter einer neuen Adresse, setze den Link direkt darauf — nicht auf eine Weiterleitung. In WordPress stehen solche Links oft hart im Beitragstext oder im Menü. In Shopware und JTL-Shop stecken sie meist in Kategoriebeschreibungen und Cross-Selling. Bei Shopify sind Navigation und Theme-Bausteine die üblichen Verdächtigen. Bei mehr als einer Handvoll Treffern lohnt ein vollständiger Crawl.

Quelle

Google Search Central: „How HTTP status codes affect Google's crawlers“ — „Any content Google receives from URLs that return a 4xx status code is ignored.“ Abgerufen 23.09.2026.

Ohne JavaScript kommt kein Inhalt an: die Seite ist eine App-Hülle

Was das heißt

Der Check lädt nur das HTML vom Server. Antwortet eine Seite mit Status 200, enthält aber fast keinen Text und keine internen Links, dafür mindestens fünf Skripte, steht im Ergebnis „Die Startseite liefert ohne JavaScript keinen Inhalt“ — bei mehreren Treffern „X von Y Seiten liefern ohne JavaScript keinen Inhalt“. Google nennt das Muster App-Shell-Modell: Das erste HTML enthält den Inhalt noch nicht, er entsteht erst im Browser. Alle weiteren Befunde des Laufs gelten dann nur für das, was ein Crawler ohne Rendering bekommt.

Warum es zählt

Google kann JavaScript ausführen, aber in zwei Schritten: erst crawlen, dann rendern. Die Seite wartet dabei in einer Warteschlange — Google schreibt, das könnten wenige Sekunden sein, es kann aber auch länger dauern. Dieselbe Doku hält fest, dass Server-Side- oder Pre-Rendering trotzdem eine gute Idee bleibt, weil nicht alle Bots JavaScript ausführen können. Das ist der Punkt für KI-Sichtbarkeit: Wer nicht rendert, sieht bei dir eine leere Hülle. Warum Crawlbarkeit auch in der KI-Suche die erste Stufe bleibt: GEO vs. SEO.

So behebst du es

Inhalt und Navigation serverseitig rendern oder vorrendern, damit Text und Links schon im HTML stehen. Danach gegenprüfen: Google Search Console, URL-Prüfung, „Gerendertes HTML“. Shopware, WordPress und JTL-Shop liefern von sich aus serverseitiges HTML — dort entsteht der Befund meist durch Headless-Aufbauten oder nachgeladene Produktlisten. Bei Shopify sind es überwiegend Apps, die Inhalte erst im Browser einsetzen.

Quelle

Google Search Central: „Understand the JavaScript SEO basics“ — „Some JavaScript sites may use the app shell model where the initial HTML does not contain the actual content“; „server-side or pre-rendering is still a great idea because it makes your website faster for users and crawlers, and not all bots can run JavaScript.“ Abgerufen 23.09.2026.

Langsame Server-Antwort: mehr als 0,8 Sekunden bis zum HTML

Was das heißt

Der Check misst je Seite die Zeit vom Abruf bis zum vollständigen HTML — ohne Bilder, Skripte und Schriften. Braucht eine Seite länger als 0,8 Sekunden, erscheint sie unter „X Seite(n) mit langsamer Server-Antwort“, mit dem gemessenen Wert in Millisekunden. Das ist kein Urteil über die gefühlte Ladezeit im Browser, sondern über deren Anfang.

Warum es zählt

Die 0,8 Sekunden sind keine Hausnummer von mir: web.dev nennt für die Server-Antwort (Time to First Byte) 0,8 Sekunden als Zielwert, ab 1,8 Sekunden gilt der Wert als schlecht. Google beschreibt außerdem, wovon die Crawl-Kapazität abhängt: Bleiben Latenz und Antwortzeiten stabil oder verbessern sich, steigt das Limit und Google crawlt mehr; wird die Website langsamer, sinkt es und Google crawlt weniger. Für Besucher liegt vor dem ersten sichtbaren Pixel die komplette Wartezeit.

So behebst du es

In dieser Reihenfolge: Seiten-Caching einschalten, damit Seiten nicht bei jedem Aufruf neu gebaut werden. Dann die teuren Datenbankabfragen suchen. Erst danach über größeres Hosting reden. In WordPress heißt das Caching-Plugin plus Objekt-Cache und weniger Plugins. In Shopware 6 der HTTP-Cache mit Warmup, bei großen Katalogen zusätzlich Elasticsearch. In JTL-Shop Objekt- und Seitencache im Backend. Bei Shopify gehört der Server nicht dir — dort helfen nur ein schlankeres Theme und weniger Apps. Welche Apps, Plugins und Theme-Skripte dabei die üblichen Verdächtigen sind: Shopify SEO und Shopware SEO.

Quelle

web.dev: „Time to First Byte (TTFB)“ — „most sites should strive to have a TTFB of 0.8 seconds or less“; „Good TTFB values are 0.8 seconds or less, and poor values are greater than 1.8 seconds.“ Abgerufen 23.09.2026. Zur Crawl-Kapazität: Google Search Central: „Optimize your crawl budget“ — „If the site slows down … the limit goes down and Google crawls less.“ Abgerufen 23.09.2026.

Interne Links zeigen auf Weiterleitungen: ein Umweg bei jedem Klick

Was das heißt

Ruft der Check eine intern verlinkte Adresse ab und der Server antwortet mit einer Weiterleitung auf dieselbe Domain, wird das gezählt. Im Ergebnis steht „X interne Links zeigen auf Weiterleitungen“, darunter je Treffer die alte und die neue Adresse mit Pfeil. Die Zielseite ist in Ordnung — nur der Weg dorthin hat einen Schritt zu viel.

Warum es zählt

Einzeln ist das kein Drama: Google folgt Weiterleitungen und wertet eine 301 als starkes Signal dafür, dass das Ziel verarbeitet werden soll. Zwei Dinge bleiben. Erstens dauert jeder Aufruf länger, weil zweimal gefragt wird — bei jedem Menüklick jedes Besuchers. Zweitens warnt Google im Leitfaden zum Crawl-Budget ausdrücklich vor langen Weiterleitungsketten, die sich negativ auf das Crawlen auswirken; Googles Crawler folgen standardmäßig höchstens zehn Sprüngen. Nach einem Relaunch stapeln sich solche Ketten schnell, weil alte Regeln nie aufgeräumt werden.

So behebst du es

Die Weiterleitungen bleiben, sie fangen alte Links von außen auf. Geändert werden deine eigenen Links: direkt auf die Zieladresse. Meistens sitzen sie an einer Stelle — Menü, Footer, Template. Typische Ursachen sind http statt https, ein fehlender oder doppelter Schrägstrich am Ende und alte Kategoriepfade. Wer die Regeln pflegt, ersetzt Ketten durch eine direkte Weiterleitung von der ältesten Adresse auf die aktuelle.

Quelle

Google Search Central: „Optimize your crawl budget“ — „Avoid long redirect chains, which have a negative effect on crawling.“ Abgerufen 23.09.2026. Zur Zahl der Sprünge und zur Wertung von 301: „How HTTP status codes affect Google's crawlers“ — „Google's crawlers follow up to 10 redirect hops“; „Google follows the redirect, and Google systems use the redirect as a strong signal“. Abgerufen 23.09.2026.

Interne Links, die nach draußen weiterleiten

Was das heißt

Manche Adressen sehen intern aus, der Server schickt den Aufruf aber auf eine andere Domain. Der Check meldet „X interne Links führen auf eine andere Domain“ und zeigt je Treffer die interne Adresse und das externe Ziel. In der Praxis sind das alte Kampagnenpfade, Links auf ein Portal oder ein Kurzlink-Dienst, der über die eigene Domain läuft.

Warum es zählt

Für Besucher ist es ein unerwarteter Seitenwechsel: Sie klicken bei dir und stehen plötzlich woanders, oft ohne die Navigation, die sie gerade benutzt haben. Für Suchmaschinen ist die interne Adresse damit kein eigener Inhalt mehr, sondern ein Verweis auf fremdes Gebiet — die interne Verlinkung, die du aufgebaut hast, kommt bei jemand anderem an. Und ist es ein alter Pfad, an den niemand mehr denkt, führt dein Menü Besucher aus dem Shop heraus.

So behebst du es

Erst die Frage: Ist die Weiterleitung gewollt? Wenn ja, etwa bei einem externen Buchungssystem, dann setze den Link direkt auf das externe Ziel — der Umweg fällt weg, der Wechsel ist erkennbar. Wenn nein, lass den internen Link auf die richtige eigene Seite zeigen und nimm die Regel heraus. Zu finden sind die Regeln in der Serverkonfiguration oder im Weiterleitungsbereich deines Systems: Shopware bei den SEO-URLs, WordPress im Redirect-Plugin, Shopify unter „URL-Weiterleitungen“, JTL-Shop im Backend.

Quelle

Google Search Central: „Redirects and Google Search“ — „Permanent redirects: Show the new redirect target in search results.“ Dazu „How HTTP status codes affect Google's crawlers“ — „Any content Google receives from the redirecting URL is ignored, and the final target URL's content is processed instead.“ Beide abgerufen 23.09.2026.

Seiten werden unkomprimiert ausgeliefert

Was das heißt

Der Check fragt deine Seiten mit den gängigen Verfahren gzip und deflate an und sieht nach, ob der Server komprimiert antwortet. Antwortet eine Seite ab 30 Kilobyte ohne Kompression, steht im Ergebnis „X Seite(n) werden unkomprimiert ausgeliefert“, mit der Größe je Adresse. Komprimiert ist dieselbe Seite in der Regel ein Bruchteil davon, weil Quelltext aus sehr vielen Wiederholungen besteht.

Warum es zählt

Jedes Kilobyte, das nicht nötig ist, kostet Zeit — im Mobilnetz deutlich mehr als im Büro-WLAN. Der HTTP-Standard ist an der Stelle eindeutig: Server sollen Daten so weit wie möglich komprimieren. Aus unseren Audits kommt der zweite Grund, sich das genau anzusehen: Fehlende Kompression ist fast immer ein Zeichen dafür, dass an der Serverkonfiguration noch nie jemand gearbeitet hat. Dann liegt meist noch mehr Einfaches daneben — Caching, Zeichensatz, Header.

So behebst du es

Kompression am Webserver oder am CDN einschalten: Brotli bevorzugt, gzip als Rückfallebene — gzip muss aktiv bleiben, sonst gehen Clients ohne Brotli leer aus, mein Check eingeschlossen. Bei Apache über die Module für Deflate beziehungsweise Brotli, bei Nginx über die entsprechenden Direktiven, bei Cloudflare und anderen CDNs mit einem Schalter. Bei Managed-Hosting und bei Shopify liegt die Einstellung nicht bei dir — dort ist das eine Frage an den Anbieter, keine Aufgabe im Backend. Danach den Check erneut laufen lassen: Der Befund verschwindet sofort oder gar nicht.

Quelle

Erfahrungswert aus unseren Audits — eine Prozentgrenze, ab der Kompression „nötig“ wird, gibt es nicht. Zum Verfahren: MDN: „Content-Encoding header“ (Standard) — „Servers should compress data as much as possible, and should use content encoding where appropriate.“ Abgerufen 23.09.2026.

Der Server hat den Crawler gebremst: 429 und ein unvollständiger Bericht

Was das heißt

Statuscode 429 bedeutet „zu viele Anfragen“. Der Server hat unsere Abrufe abgewiesen, weil sie zu schnell kamen. Im Ergebnis steht „Der Server hat den Crawler gebremst (429 bei X Seiten)“. Dieser Befund zählt nicht in den Score, denn er sagt nichts über deine Website, sondern über einen Bot-Schutz. Wichtig ist die Folge: Was in diesem Lauf zu Titeln, Texten und Links steht, ist unvollständig.

Warum es zählt

Zwei Gründe. Erstens für dich als Leser: Ein fehlender Befund heißt hier „nicht geprüft“, nicht „in Ordnung“. Wiederhole den Lauf, bevor du Schlüsse ziehst. Zweitens: Ein Schutz, der nach wenigen Abrufen zuschlägt, trifft nicht nur mein Werkzeug. In unseren Audits sind das meist eng eingestellte Bot-Schutz-Dienste. Was ein 429 bei Googlebot auslöst, ist dokumentiert: Google liest den Code als Zeichen für einen überlasteten Server, behandelt ihn als Serverfehler und crawlt vorübergehend langsamer. Ob auch Suchmaschinen betroffen sind, sagt dir nur die Crawling-Statistik in der Search Console.

So behebst du es

Zuerst in einigen Minuten erneut prüfen; oft war es nur eine Spitze. Bleibt es dabei, ist der Bot-Schutz eng gestellt: bei Cloudflare die Regeln für Bots und Rate-Limiting ansehen, bei Managed-Hosting beim Anbieter nachfragen, bei Shopify die Grenze hinnehmen. Dann in der Search Console unter Einstellungen die Crawling-Statistik öffnen; dort stehen Antwortcodes und Verfügbarkeitsprobleme für Googlebot. Dieselbe Regel trifft die KI-Crawler: Perplexity veröffentlicht die IP-Bereiche seiner Bots, damit du sie gezielt freigeben kannst statt pauschal zu blocken — Perplexity-SEO.

Quelle

Die Schwelle, ab der mein Check gebremst wird, ist ein Erfahrungswert aus unseren Audits. Zum Statuscode selbst: MDN: „429 Too Many Requests“ (Standard, definiert in RFC 6585) — „indicates the client has sent too many requests in a given amount of time“. Zur Wirkung bei Googlebot: Google Search Central: „How HTTP status codes affect Google's crawlers“ — „Google's crawlers treat the 429 status code as a signal that the server is overloaded, and it's considered a server error“; „5xx and 429 server errors prompt Google's crawlers to temporarily slow down with crawling.“ Alle abgerufen 23.09.2026.

Keine Sprachangabe im HTML: das lang-Attribut fehlt

Was das heißt

Der Check sieht sich das html-Element deiner Startseite an. Fehlt dort das lang-Attribut, meldet er „Keine Sprachangabe im HTML“ mit dem Hinweis, dass Sprachmodelle und Screenreader die Sprache raten müssen. Richtig wäre bei einer deutschen Seite <html lang="de">. Der Befund ist gelb und kostet fünf Punkte, genauso viele wie fehlendes HTTPS — ein Hinweis, kein Fehler.

Warum es zählt

Die Angabe sagt jedem Programm, das deine Seite liest, in welcher Sprache sie geschrieben ist. Screenreader wählen danach Stimme und Aussprache; ohne Angabe liest eine englische Stimme deutschen Text vor, praktisch unverständlich. Browser entscheiden danach über Trennregeln und über das Übersetzungsangebot. Und Sprachmodelle bekommen einen Hinweis mehr statt einer Vermutung. Der Standard empfiehlt ausdrücklich, immer einen passenden Wert zu setzen, besonders wegen der Barrierefreiheit. Eine Ranking-Wirkung verspreche ich dir nicht — es ist eine Zeile, die nichts kostet.

So behebst du es

Eine Zeile im Template: <html lang="de">. Bei mehrsprachigen Seiten je Sprachversion der passende Code, bei einzelnen fremdsprachigen Textstellen das Attribut am Absatz. In WordPress setzt du die Sprache der Website in den Einstellungen, das Theme trägt sie im Kopf ein. Shopware und JTL-Shop setzen sie je Verkaufskanal und Sprache. Bei Shopify steht sie meist schon im Theme, sonst ergänzt du sie dort. Danach im Quelltext nachsehen, ob wirklich ein Wert drinsteht.

Quelle

Erfahrungswert aus unseren Audits — für Sprachmodelle gibt es dazu keine offizielle Vorgabe. Zum Attribut selbst: MDN: „lang HTML global attribute“ (Standard) — „It is recommended to always specify an appropriate value for this attribute, especially due to accessibility concerns.“ Abgerufen 23.09.2026.

In welcher Reihenfolge du das abarbeitest

Wenn du mehrere dieser Befunde gleichzeitig im Bericht hast, ist die Reihenfolge fast immer dieselbe:

1. HTTPS — ohne das liest niemand weiter, und alles andere wird doppelt.
2. Fehlerseiten und tote Links — das Einzige in dieser Liste, was Seiten aus dem Index nimmt.
3. JavaScript-Hülle — größter Aufwand, größte Wirkung, gehört in die Entwicklung.
4. Antwortzeit — Caching zuerst, Hosting zuletzt.
5. Weiterleitungen — meist eine Template-Änderung an einer Stelle.
6. Kompression und lang-Attribut — jeweils eine Zeile, macht man mit.

Prüf deine Domain

Der Website-Check ruft deine Seiten ab und liefert genau diese Befunde für deine Domain — mit den betroffenen Adressen und den gemessenen Werten. Das Ergebnis des Website-Checks verlinkt bei jedem Befund genau hierher. Domain eingeben, Ergebnis lesen, abarbeiten.