Die meisten Corporate Websites verlieren Sichtbarkeit aus Gründen, die niemand im Browser sehen kann: Seiten, die Suchmaschinen nicht erreichen, Duplikate, die miteinander konkurrieren, Templates, die langsam rendern, Markup, das nichts sagt. Ein technisches SEO-Audit findet sie. Diese Checkliste ist die, mit der wir bei Corporate- und B2B-Websites arbeiten — groß, mehrsprachig, oft auf einem Enterprise-CMS — und sie ist so geschrieben, dass ein Marketing- oder Digitalteam den ersten Durchgang ohne Agentur schafft.
Die Idee
Technische SEO ist keine Liste von Tricks. Sie ist der technische Zustand einer Website aus Sicht eines Crawlers: Kann jede wichtige Seite gefunden, verstanden, schnell gerendert und als vertrauenswürdig eingestuft werden? Ein Audit prüft das in dieser Reihenfolge, priorisiert die Befunde nach Geschäftswirkung und endet mit einem Plan, den jemand bauen kann — nicht mit einem 200-seitigen Export.
Die Reihenfolge zählt. Strukturierte Daten auf Seiten zu reparieren, die Google nicht crawlen kann, ist vergeudete Arbeit; Templates zu beschleunigen, die per robots.txt gesperrt sind, ändert nichts. Beginnen Sie oben in dieser Liste und arbeiten Sie sich nach unten.
Warum es zählt
Auf einer Website mit Tausenden Seiten liegt der verlorene Traffic meist in der Lücke zwischen dem, was existiert, und dem, was indexiert ist. Eine Corporate Website, die zweimal neu gestaltet, einmal migriert und zehn Jahre lang von vielen Händen bearbeitet wurde, sammelt Redirect-Ketten, verwaiste Bereiche, vergessene Sprachordner und Parameter-URLs, die alles verwässern. Nichts davon zeigt sich im Design-Review. Alles davon zeigt sich in der Search Console.
In der Praxis: die Checkliste
1. Crawlbarkeit
robots.txt — nichts Wichtiges gesperrt; Staging- und Admin-Pfade blockiert; Sitemap referenziert.
XML-Sitemaps — vorhanden, valide, nach Typ getrennt, nur kanonische, indexierbare 200-URLs; echte Last-Modified-Daten.
Website crawlen mit einem Desktop-Crawler und die URL-Zahl mit CMS und den indexierten Seiten in der Search Console vergleichen. Drei Zahlen, die ungefähr übereinstimmen sollten — und es selten tun.
Verwaiste Seiten — Seiten in Sitemap oder Logs, die kein interner Link erreicht.
Crawl-Tiefe — jede wichtige Seite innerhalb von drei Klicks von der Startseite erreichbar.
2. Indexierung
Search-Console-Abdeckung — die Listen „Gecrawlt, nicht indexiert“ und „Gefunden, nicht indexiert“ Seite für Seite lesen; sie sagen, was Google für dünn oder doppelt hält.
Canonicals — selbstreferenzierend auf jeder indexierbaren Seite; konsistent mit Sitemaps, hreflang und internen Links.
Noindex — auf Suchergebnisse, Filter, Tag-Archive, Danke-Seiten angewendet; nicht versehentlich auf etwas, das Traffic bringt.
Parameter- und Facetten-URLs — Produktfilter, Sortierungen und Tracking-Parameter über Canonicals oder Regeln kontrolliert, nicht als Tausende Beinahe-Duplikate indexiert.
Paginierung — crawlbar und selbst-kanonisch.
3. Architektur und interne Verlinkung
URL-Struktur — lesbar, stabil, kleingeschrieben, keine Session-IDs; eine URL pro Seite.
Navigation — die Hauptbereiche von jeder Seite verlinkt; wichtige tiefe Seiten aus Hubs, Footern und Related-Content-Blöcken verlinkt, nicht nur aus der Sitemap.
Interne Links — keine Links auf umgeleitete oder defekte URLs; beschreibende Ankertexte.
Redirects — 301, nicht 302, für dauerhafte Umzüge; keine Ketten länger als ein Sprung; keine Schleifen. Nach einer Migration ist das der häufigste Fehler.
4. Rendering und JavaScript
Gerendertes vs. rohes HTML — vergleichen, was ein Crawler erhält, mit dem, was der Browser zeigt. Inhalte, Links und Metadaten, die nur per clientseitigem JavaScript eingefügt werden, werden möglicherweise nicht gesehen.
Lazy Loading — Bilder und Inhalte weiterhin auffindbar; keine Listen, die nur per Infinite Scroll erreichbar sind.
Blockierte Ressourcen — CSS und JS, die Google zum Rendern braucht, sind nicht gesperrt.
5. Performance und Core Web Vitals
Felddaten — der Core-Web-Vitals-Bericht der Search Console und CrUX, nicht nur Laborwerte; nach Template gruppieren.
LCP — Hero-Bilder dimensioniert, komprimiert und vorgeladen; Schriften subsettet und vorgeladen; kein render-blockierendes CSS im kritischen Pfad.
INP — schwere Skripte, Tag-Manager und Animationsbibliotheken verzögert oder entfernt.
CLS — Bildmaße gesetzt; Schriften mit Fallback-Metriken; keine spät eingefügten Banner.
Caching und Auslieferung — CDN, Kompression, Cache-Header, Bildformate (AVIF/WebP).
6. On-Page und Metadaten
Titel und Beschreibungen — einzigartig, spezifisch, in der Länge; Templates, die für Tausende Produkt- oder Nachrichtenseiten sinnvolle Standards erzeugen.
Überschriften — eine H1, eine logische H2/H3-Struktur, die den Inhalt spiegelt, nicht das Design.
Bilder — beschreibende Dateinamen und Alt-Texte, wo das Bild Bedeutung trägt.
Dünne und doppelte Inhalte — nahezu identische Seiten konsolidiert oder differenziert.
7. Strukturierte Daten
Organization — Name, Logo, sameAs, Standorte, auf jeder Seite über den Site-Graph.
Seitentypen — Article, Product, FAQPage, BreadcrumbList, JobPosting, wo relevant; aus dem Content-Modell erzeugt, damit Redakteure es nicht kaputt machen können.
Validierung — Test für Rich-Suchergebnisse und Verbesserungsberichte der Search Console; keine Fehler, wenige Warnungen.
8. International
hreflang — jede Sprach-/Marktversion einer Seite referenziert alle anderen und sich selbst; Rücklinks konsistent; x-default gesetzt.
Struktur — ein klares Muster (Unterordner, Subdomain oder ccTLD), überall angewendet.
Unübersetzte Seiten — nicht als Duplikate der Quellsprache veröffentlicht.
9. Sicherheit und Hygiene
HTTPS überall, ein kanonischer Host (www oder nicht), HTTP umgeleitet.
Fehlerbehandlung — echter 404-Status für fehlende Seiten, keine Soft-404s; eine nützliche 404-Seite.
Alte Properties — stillgelegte Domains, Staging-Websites und Legacy-Microsites umgeleitet oder aus dem Index entfernt.
10. Monitoring
Search Console — Abdeckung, Verbesserungen und Core Web Vitals monatlich geprüft; Alarme bei Fehlerspitzen.
Logdateien — wo verfügbar: was Crawler tatsächlich abrufen und wie oft.
Change Control — jede Template-, CMS- oder Hosting-Änderung vor dem Release gegen diese Liste geprüft.
Was zu tun ist
Bearbeiten Sie zuerst die Abschnitte 1–3; sie entscheiden, ob alles andere überhaupt zählt. Fassen Sie die Befunde in einem priorisierten Dokument mit drei Spalten zusammen: Wirkung, Aufwand, Verantwortlicher. Beheben Sie Redirects, Canonicals und gesperrte Seiten, bevor Sie die Performance anfassen. Behandeln Sie den Rest als Engineering-Arbeit mit Releases und Verifikation — denn genau das ist es.
Wenn die Fixes Änderungen an Templates, CMS oder Front-end erfordern, gehören sie zu dem, der die Website entwickelt. Deshalb machen wir technische SEO als Teil des Bauens und Betreibens von Websites — nicht als separaten Bericht. Siehe unsere Seite Technische-SEO-Agentur oder lesen Sie Wie man eine Technische-SEO-Agentur auswählt.
FAQ
Wie oft sollte eine Corporate Website auditiert werden?
Ein vollständiges Audit einmal im Jahr und vor jedem Relaunch oder jeder Migration; die Abschnitte 1–3 und Core Web Vitals quartalsweise oder nach jedem größeren Release.
Welche Werkzeuge braucht man?
Einen Desktop-Crawler, die Google Search Console, PageSpeed Insights oder CrUX-Daten, den Test für Rich-Suchergebnisse und — bei großen Websites — Zugriff auf Server-Logs. Der größte Teil des Werts kommt aus dem sorgfältigen Lesen der Ergebnisse, nicht aus dem Werkzeug.
Geht ein Audit ohne Entwicklerzugang?
Das Audit ja. Die Fixes selten. Planen Sie von Anfang an Engineering-Zeit ein.
Sie möchten das Audit für sich durchführen lassen? Technisches SEO-Audit anfragen — wir liefern einen priorisierten, umsetzbaren Plan und können ihn umsetzen.