Bevor wir technisches SEO als Leistung anboten, haben wir das getan, was die meisten Agenturen auslassen: Wir haben den Prozess auf uns selbst angewendet.
Wir haben ein vollständiges technisches Audit von prixelo.com durchgeführt. Keine Staging-Umgebung, keine Demo-Seite – die echte Website, die potenzielle Kunden sich ansehen, bevor sie uns eine E-Mail schreiben. Wir hatten mit einer Handvoll kleinerer Probleme gerechnet. Gefunden haben wir sieben Dinge, die aktiv gegen uns arbeiteten.
Dieser Beitrag ist genau dieses Audit, unbearbeitet. Kein zusammengesetzter Beispielkunde, keine erfundene Fallstudie. Nur das, was wir auf unserer eigenen Website gefunden haben – und was jeder einzelne Bug darüber verrät, wie Suchmaschinen eine Seite tatsächlich sehen, im Unterschied dazu, wie ein Browser sie darstellt.
Die Sitemap erfasste den Großteil der Website nicht
Wir haben sitemap.xml aufgerufen und eine reine Formalität erwartet. Stattdessen fanden wir eine Datei, die nur einen Bruchteil unserer echten Seiten auflistete. Ganze Bereiche der Website – veröffentlichte, intern verlinkte Seiten, von denen wir ein Ranking erwarteten – fehlten einfach.
Eine Sitemap ist kein Nice-to-have. Sie ist die Karte, die Sie Google an die Hand geben, damit es Ihre Websitestruktur nicht allein durch das Verfolgen von Links erraten muss. Eine Seite, die live ist, intern verlinkt wird und in der Sitemap fehlt, kann trotzdem irgendwann indexiert werden – aber langsamer, unzuverlässiger, und es signalisiert Crawlern, dass die Metadaten Ihrer Website nicht vertrauenswürdig sind. Wenn die Sitemap einmal falsch liegt, hat ein Crawler weniger Grund, sie auch anderswo als maßgeblich zu behandeln.
Unser Organization-JSON-LD war auf der gesamten Website kaputt
Wir prüfen strukturierte Daten routinemäßig mit einem Validator. Unsere sind durchgefallen. Auf jeder einzelnen Seite.
Die Ursache war ein Escaping-Bug im Template – ein Zeichen in unserem Organization-Schema wurde beim Rendern falsch kodiert, wodurch der JSON-LD-Block auf jeder einzelnen Seite, auf der er erschien, syntaktisch ungültig war. Google parst kaputtes JSON nicht teilweise. Entweder es wird sauber geparst, oder der gesamte Block wird verworfen. Wie lange das schon so lief, wissen wir nicht genau – aber es bedeutete: null strukturierte Daten erreichten Google, website-weit, während wir dachten, wir hätten vollständiges Markup. Das ist genau die Art Bug, die im Browser keinen Fehler erzeugt – die Seite sieht einwandfrei aus – und keine Warnung auslöst, außer man sucht gezielt in einem Schema-Validator oder im Rich-Results-Bericht der Search Console danach.
Soft-404s mit HTTP-Status 200
Einige defekte oder entfernte URLs auf der Website lieferten keinen 404-Status zurück. Stattdessen wurde Fallback-Content ausgeliefert – eine generische Seite –, während der Server Browser und Crawlern gleichermaßen mitteilte: „200 OK, diese Seite existiert.“
Das ist ein Soft-404, und er ist schlimmer als ein echter. Ein echter 404 sagt Suchmaschinen klar: Diese URL existiert nicht mehr, aus dem Index nehmen. Ein Soft-404 sagt: Diese URL ist in Ordnung, bitte weiter crawlen und indexieren, obwohl hier nichts ist. Bleibt das unbemerkt, verschwendet das Crawl-Budget auf Seiten, die es gar nicht gibt, und kann verwässern, wie Ihre echten Seiten bewertet werden – weil der Crawler Zeit und Vertrauen auf Sackgassen verschwendet, die vorgeben, live zu sein.
Canonical-Tags, die auf die falsche Domain zeigten
Mehrere Seiten hatten Canonical-Tags, die auf die Non-www-Version unserer eigenen Domain verwiesen – die selbst wiederum auf eine andere Adresse weiterleitet. Ein Überbleibsel aus einem früheren Setup. Ein Canonical-Tag ist eine direkte Anweisung an Suchmaschinen: „Diese URL als maßgebliche Version indexieren – nicht die, die gerade aufgerufen wird.“ Zeigt er auf die falsche Adresse, sagen Sie Google damit explizit, eine andere URL für Ihren eigenen Content zu würdigen. Bestenfalls wird das ignoriert. Schlimmstenfalls leiten Sie Ihre eigenen Ranking-Signale aktiv von genau der Seite weg, die sie braucht.
Meta-Descriptions, mitten im Wort abgeschnitten
Kleiner, aber genau die Art Detail, die in der Summe Vertrauen kostet: Mehrere Meta-Descriptions wurden bereits im rohen HTML mitten im Wort abgeschnitten – nicht erst bei der Anzeige in den Suchergebnissen gekürzt. Das ist ein Bug im Template oder in der Zeichenbegrenzung, kein reines Anzeigeartefakt, und er zeigt sich als unvollständige Sätze in Ihren <meta>-Tags – sichtbar für jeden, der sich den Quellcode ansieht, und ein kleines, aber echtes Signal von Nachlässigkeit auf einer Seite, die glaubwürdig wirken will.
Eine veraltete robots.txt aus einem Verzeichnis, das älter war als die aktuelle Website
Das war der seltsamste Fund. Die ausgelieferte robots.txt war nicht die aus unserer aktuellen Codebasis. Sie kam aus einem übrig gebliebenen Legacy-Verzeichnis auf dem Server – einem Überrest einer früheren Version der Website, die eigentlich komplett hätte stillgelegt werden müssen. Die laufende Anwendung wusste nicht einmal, dass diese Datei existierte oder dass genau sie es war, die Crawler tatsächlich lasen.
robots.txt ist eine der ersten Dateien, die ein Crawler anfragt. Ist die ausgelieferte Version veraltet, kann sie Pfade blockieren, die crawlbar sein sollten, andere freigeben, die es nicht sein sollten, oder schlicht auf eine Sitemap verweisen, die es gar nicht mehr gibt. Und weil sie außerhalb des normalen Deploy-Pfads liegt, bleibt sie für jeden unsichtbar, der nur die aktuelle Codebasis prüft – man muss kontrollieren, was tatsächlich unter der URL ausgeliefert wird, nicht, was man zu deployen glaubt.
Seiten, die Crawlern „nicht gefunden“ meldeten – wegen rein clientseitiger Slug-Erkennung
Der letzte Punkt ist ein Problem beim JavaScript-Rendering – eine häufige Falle bei allem, was mit clientseitigem Routing gebaut ist. Bestimmte Seiten entschieden erst anhand eines Slugs, welcher Inhalt angezeigt wird, und dieser Slug wurde erst im Browser aufgelöst, nachdem das JavaScript gelaufen war. Crawler, die clientseitiges JavaScript nicht vollständig ausführen – oder die aussteigen, bevor es aufgelöst ist –, treffen auf die ursprüngliche Serverantwort, finden keinen passenden Slug und bekommen einen „Nicht gefunden“-Zustand ausgeliefert. Für einen Menschen funktioniert die Seite einwandfrei. Für einen Crawler, der nie so weit kommt, den eigentlichen Inhalt zu sehen, ist sie unsichtbar oder kaputt.
Was uns das eigentlich zeigt
Keiner dieser Bugs ist exotisch. Es sind die typischen Fehlerbilder jeder Website, die über ihre erste Version hinausgewachsen ist: Legacy-Infrastruktur, die niemand abgeschaltet hat, eine Template-Änderung, die stillschweigend die Kodierung kaputt gemacht hat, ein Routing-Muster, das für Nutzer optimiert, aber nie gegen das Verhalten von Crawlern geprüft wurde. Jeder einzelne davon war in einem normalen Browser unsichtbar – und blieb es, solange niemand gezielt danach suchte, wie ein Crawler die Seite sieht, statt wie ein Mensch.
Genau das ist die eigentliche Aufgabe. Technisches SEO sind keine Keyword-Vorschläge oder Content-Kalender – es geht darum, die Lücke zu finden zwischen dem, wie Ihre Website für Sie aussieht, und dem, wie sie für die Systeme aussieht, die entscheiden, ob sie indexiert und gerankt wird. Wir haben alle sieben Probleme auf unserer eigenen Website behoben – als Teil des Aufbaus unseres SEO-Angebots, denn wir wollten kein Audit verkaufen, das wir nicht zuerst an uns selbst durchgeführt hatten.
Wenn Sie wissen wollen, ob Ihre eigene Website vergleichbare Probleme hat: Genau das prüft unser SEO-Team als Erstes – noch vor jedem Gespräch über Content oder Rankings.
