Technisches SEO

Wenn eine Seite in der Suche fehlt, kann die Ursache in der Auffindbarkeit, im Zugriff, im Rendering, in widersprüchlichen Canonicals, in einer Indexierungsentscheidung, in schwachen internen Verweisen oder schlicht in mangelnder Relevanz liegen. Im Traffic-Diagramm sehen diese Fälle oft gleich aus. Deshalb verfolgen wir den Weg von der aufgerufenen URL über Weiterleitungen, Header, Quell-HTML, gerenderten Inhalt, Sprachsignale, strukturierte Daten, interne Links und Sitemap-Einträge, bevor wir eine Maßnahme empfehlen.

Das Audit richtet sich nach der tatsächlichen Website und nicht nach einer beliebigen Prüfliste. Eine mehrsprachige Unternehmensseite, eine JavaScript-Anwendung, ein Katalog mit Tausenden Datensätzen und eine bevorstehende Migration haben unterschiedliche Risiken. Wir untersuchen repräsentative Vorlagen und Routenfamilien und prüfen anschließend Sonderfälle. Search Console, Server-Logs und Analytics fließen ein, sofern Zugriff und Datenqualität ausreichen. Maßgeblich für die ausgelieferte Live-Version bleibt eine unabhängige öffentliche Abfrage.

Ein technisches SEO-Audit kann Hunderte Hinweise liefern, obwohl nur wenige wertvolle Seiten betreffen. Wir gewichten den gefährdeten Such- oder Geschäftsweg, die Reichweite über Vorlagen, die Sicherheit der Diagnose, den Änderungsaufwand und das Regressionsrisiko. Websiteweite Blockaden und umsatzrelevante Seitentypen stehen vor kosmetischen Warnungen, die ein Werkzeug lediglich rot markiert hat.

Jede Empfehlung benennt die zuständige Schicht und einen Abnahmetest. Manche Korrekturen gehören in Server oder CDN, andere in Routing, Vorlagen, Inhalt, CMS-Regeln oder Analyse. Abhängigkeiten bleiben sichtbar: Ein Canonical ist nicht repariert, solange Weiterleitung und interne Links die alte Adresse bevorzugen. Bei Migrationen werden Alt-Neu-Inventar, Redirect-Map, Canonicals, Sprachbeziehungen, Sitemap-Wechsel und Rückfallbedingungen vor dem Start festgelegt.

Wenn Technologie, Zugriff und Auftrag es zulassen, gehört die Umsetzung zum Mandat. Wir ändern die gepflegte Quelle statt eines kurzlebigen Build-Artefakts und halten den Diff eng. Weiterleitungen, Canonicals, Indexierungsregeln, hreflang, strukturierte Daten, interne Links und Sitemaps stützen dieselbe öffentliche Identität. Strukturierte Daten spiegeln sichtbare, belegbare Tatsachen; sie erfinden weder Standorte noch Bewertungen, Kunden oder Ergebnisse.

Bei der Performance zählen tatsächliche Auslieferung und Nutzung: Antwortzeit, blockierende Ressourcen, Bildabmessungen, Schriftverhalten, JavaScript-Kosten und Layout-Stabilität auf repräsentativen Geräten. Für KI-Suche bleibt die technische Grundlage das öffentliche Web. Kein Spezial-Tag ersetzt indexierbare Inhalte, eindeutige Entitäten, nützliche Belege und gewöhnlichen Crawl-Zugriff. Optionale maschinenlesbare Dateien können andere Systeme orientieren, sind aber keine Abkürzung für Google-Rankings.

Quelle, erzeugtes Paket und öffentliche Website werden als drei eigene Zustände geprüft. Das Release-Manifest enthält nur beabsichtigte Routen und benötigte gemeinsame Assets. Nach dem Upload werden öffentliche Bytes und Semantik erneut verglichen, benannte Crawler stichprobenartig getestet, wichtige Seiten in schmalen und breiten Viewports geöffnet und eine wiederherstellbare Sicherung behalten. Ein lokaler Test oder Upload-Beleg genügt nicht.

Suchmeldungen werden als Meldungen protokolliert. Crawling, Indexauswahl, Impressionen, Positionen, KI-Zitate und qualifizierte Anfragen entstehen zu unterschiedlichen Zeiten und werden getrennt gemessen. Search-Console-Daten werden erst bei ausreichendem Zeitraum mit einem datierten Ausgangswert verglichen. Das Mandat schließt anhand der technischen Abnahmekriterien im schriftlichen Umfang; noch ausstehende Plattformentscheidungen bleiben ausdrücklich offen.