SEO · Technisches Fundament

Technisches SEO. Das Fundament, das niemand sieht.

Crawlability, Indexierung, Rendering, Performance, strukturierte Daten, interne Linklogik. Ohne ein sauberes technisches Fundament greifen Content und Backlinks nur teilweise. Wir bauen es so, dass alle späteren Maßnahmen ungebremst arbeiten.

Technisches SEO ist die unsichtbare Schicht jeder organischen Sichtbarkeits-Strategie. Solange Google eine Seite nicht crawlen, rendern und korrekt indexieren kann, ist jede inhaltliche Optimierung wirkungslos. Diese Seite beschreibt vollständig, welche technischen Hebel wir bei DAMA Solutions ziehen, in welcher Reihenfolge wir das tun und wie wir den wirtschaftlichen Effekt messbar machen. Wer den größeren Rahmen sehen möchte, findet ihn in der SEO-Pillar-Seite.

Warum technisches SEO zuerst kommt

In nahezu jedem Mandat starten wir mit einer technischen Bestandsaufnahme — selbst dann, wenn das eigentliche Anliegen Content-Aufbau oder Linkbuilding ist. Der Grund ist simpel: Eine einzige falsche Direktive in der robots.txt, ein paginierter Bereich ohne saubere Indexierungs-Logik oder ein render-blockiertes JavaScript kann die Wirkung sechs- bis zwölfmonatiger redaktioneller Arbeit zu einem Bruchteil eindampfen. Wir wollen wissen, gegen welche Decken spätere Maßnahmen anlaufen, bevor wir sie aufsetzen.

Technisches SEO ist dabei kein abgeschlossenes Projekt, sondern eine laufende Aufgabe. Jedes größere Release, jede Template-Änderung, jede Migration kann Regressionen einführen — und tut es regelmäßig auch. Wir betreuen technische SEO-Schichten deshalb im Retainer mit kontinuierlichem Monitoring, nicht als einmalige Optimierung.

Crawling und Crawl-Budget

Google entscheidet vor jedem Crawl, welche URLs einer Domain Aufmerksamkeit bekommen. Diese Aufmerksamkeit ist endlich. Bei mittelgroßen und großen Sites wird Crawl-Budget zu einer kritischen Ressource, die strukturell gesteuert werden muss.

Crawl-Pfade bewusst gestalten

Interne Verlinkung definiert, welche Seiten Google häufig wiederbesucht und welche im Long Tail des Crawl-Frequenzspektrums verschwinden. Pillar-Seiten und kommerzielle Kern-URLs müssen aus dem Site-weiten Linkprofil heraus dominant erreichbar sein — nicht über drei Klicks aus dem Footer.

Crawl-Fallen identifizieren

Filterkombinationen mit URL-Parametern, paginated archive deep ohne Indexierungs-Logik, sessionbasierte Tracking-IDs in URLs, fehlerhaft konfigurierte Faceted Navigation — das sind die häufigsten Crawl-Budget-Verschwender. Wir mappen sie systematisch und schließen sie über robots.txt, kanonisch saubere URL-Patterns oder noindex/follow-Direktiven.

Server-Antworten auf Plausibilität prüfen

Soft-404s, Redirect-Ketten, 5xx-Häufungen unter Last, fehlerhafte Hreflang-Antworten — all das beeinflusst, wie ernst Google eine Domain nimmt. Wir analysieren Server-Logs, kategorisieren Antworten und identifizieren strukturelle Schwächen.

Indexierungs-Steuerung

Indexierung ist die zweite Schwelle nach dem Crawl. Eine Seite kann gecrawlt werden und trotzdem nicht indexiert sein — und das ist manchmal auch korrekt so. Die strategische Frage ist: Welche URLs gehören in den Index, welche nicht, und wie wird das technisch sauber signalisiert?

Canonical-Strategie

Falsch gesetzte Canonical-Tags sind eine der häufigsten Ursachen für Sichtbarkeits-Verluste nach Relaunches. Wir prüfen jede Canonical-Direktive auf Selbstkonsistenz, auf Übereinstimmung mit Sitemap und internen Links und auf Konflikte mit Hreflang.

Noindex bewusst einsetzen

Filterseiten, Such-Ergebnisseiten, Tag-Archive, dünne PLP-Varianten — all das gehört in vielen Fällen nicht in den Google-Index. Eine sauber kuratierte Noindex-Strategie konzentriert Crawl-Budget und Ranking-Signale auf die Seiten, die tatsächlich wirtschaftlich tragen.

Sitemap-Architektur

Sitemaps sind kein Pflicht-Item, sondern ein Steuerungsinstrument. Wir segmentieren Sitemaps nach Content-Typ, halten sie strikt aktuell und nutzen sie als diagnostisches Werkzeug — die Indexierungs-Rate pro Sitemap zeigt, welche Content-Cluster Probleme haben.

Rendering: JavaScript-SEO ohne Dogma

Moderne Frontend-Frameworks — React, Vue, Next.js, TanStack Start — sind SEO-fähig, wenn sie richtig konfiguriert sind. Das ist die weniger dogmatische Wahrheit hinter der Diskussion „SPA vs. SSR". Entscheidend ist, dass die relevanten Inhalte, Meta-Tags und strukturierten Daten beim ersten HTML-Response des Servers vorhanden sind — entweder durch Server-Side Rendering, Static Generation oder Hybrid-Patterns.

Render-Pfad analysieren

Wir prüfen für jede Template-Klasse, wie der gerenderte HTML aussieht, den Googlebot tatsächlich erhält — nicht den, den der Browser nach Hydration zeigt. Differenzen zwischen beiden sind Warnzeichen.

Lazy-Loading mit Bedacht

Bilder, Iframes und sekundäre Komponenten können ohne Probleme lazy geladen werden. Inhalte, die ranken sollen, dürfen nicht erst nach Scroll-Interaktion erscheinen — Google rendert in der Regel nicht scrollend.

Core Web Vitals und Performance

Largest Contentful Paint, Interaction to Next Paint, Cumulative Layout Shift — diese drei Metriken sind seit 2021 dokumentierte Ranking-Faktoren. Wichtiger als der direkte Ranking-Einfluss ist jedoch der Effekt auf Conversion: Eine Sekunde Verzögerung im LCP kostet messbar Abschlüsse.

LCP — Largest Contentful Paint

Wir analysieren, welches Element das LCP ist, ob es priorisiert geladen wird, ob das Hauptbild WebP/AVIF nutzt, ob Schriftarten blockieren und ob der Server schnell genug TTFB liefert.

INP — Interaction to Next Paint

Der 2024er Nachfolger von FID misst, wie reaktionsfreudig eine Seite unter realer Interaktion ist. Hauptursachen schlechter INP-Werte sind überladene JavaScript-Bundles und blockierende Third-Party-Skripte. Wir prüfen Bundle-Größen, identifizieren Render-blockierende Skripte und priorisieren Hydration-Patterns.

CLS — Cumulative Layout Shift

Fehlende Bildmaße, nachgeladene Schriften ohne Fallback-Metrik, spät einblendende Banner — die typischen CLS-Verursacher sind überschaubar und mit klaren technischen Maßnahmen behoben.

Strukturierte Daten und Schema.org

Strukturierte Daten sind die Brücke zwischen Inhalt und semantischem Verständnis. Sie helfen Google, Inhalte korrekt einzuordnen, ermöglichen Rich Results und sind zunehmend Voraussetzung für Sichtbarkeit in AI-Antworten und Featured Snippets.

Sinnvolle Schema-Auswahl

Wir bauen Schema.org-Markup pro Content-Typ: Organization, LocalBusiness, Product, Article, FAQPage, BreadcrumbList, Person, Service, Event. Nicht jedes Schema bringt jedem Seitentyp Mehrwert — die Auswahl folgt der wahrscheinlichen Search-Intent und den verfügbaren Rich-Result-Formaten.

Validierung und Wartung

Schema-Implementierungen brechen regelmäßig — sei es durch CMS-Updates, Plugin-Konflikte oder Template-Änderungen. Wir setzen kontinuierliches Monitoring auf, das uns warnt, sobald strukturierte Daten ihre Validität verlieren.

Interne Linklogik als strategisches Instrument

Interne Links verteilen sowohl Crawl-Frequenz als auch Ranking-Signale. Die meisten Sites haben gewachsene, nicht gewachsen-gewollte Linkstrukturen. Wir mappen sie und gestalten sie bewusst.

Topic Authority über Hub-Strukturen

Pillar-Seiten bündeln thematische Sichtbarkeit. Sie müssen aus den zugehörigen Detail-Seiten heraus stark verlinkt sein — und umgekehrt ihre Detail-Seiten klar referenzieren. Das ist nichts anderes als die Logik, die Sie auf dieser Site gerade selbst sehen.

Linkanker bewusst wählen

Der Text eines internen Links ist ein direktes Signal an Google. Generische Anker wie „mehr erfahren" oder „hier klicken" verschenken diese Information. Wir kuratieren Anker-Profile auf semantisch relevante Begriffe — ohne ins Over-Optimization-Territorium zu kippen.

Internationalisierung und Hreflang

Wenn mehrere Sprach- oder Länder-Versionen existieren, ist Hreflang die Konfigurationsebene, die am häufigsten fehlerhaft ist. Wir prüfen bidirektionale Konsistenz, x-default-Konfiguration und Konsistenz mit Canonical-Strategie.

Migration und Relaunch — die häufigste Verlustquelle

Über die Hälfte aller schweren Sichtbarkeits-Einbrüche, die wir in Audits sehen, lassen sich auf einen fehlerhaft begleiteten Relaunch zurückführen. Die typischen Fehler: keine vollständige Redirect-Map, Verlust von strukturierten Daten, geänderte URL-Strukturen ohne Konzept, fehlende kanonische Steuerung.

Wir begleiten Migrations- und Relaunch-Projekte mit einer dedizierten SEO-Migration-Checklist, vorlaufender Crawl-Inventarisierung, Redirect-Map-Erstellung, Staging-Audits und Post-Launch-Monitoring der ersten 90 Tage.

Monitoring im laufenden Retainer

Technisches SEO ist nie „fertig". Wir betreiben für unsere Mandate kontinuierliches Monitoring auf:

  • Indexierungs-Rate pro Sitemap und Content-Typ — Warnsystem für strukturelle Indexierungsprobleme.
  • Crawl-Statistiken aus der Search Console — frühzeitige Sichtbarkeit von Crawl-Budget-Verschwendung.
  • Core Web Vitals pro Template-Klasse — getrennt nach Mobile und Desktop, mit Field- und Lab-Daten.
  • Validität strukturierter Daten — automatisierter Check auf Schema-Brüche nach Releases.
  • 404-Profile und Redirect-Ketten — Identifikation neuer Linkverluste und Redirect-Hygiene.

Werkzeuge — aber nicht als Selbstzweck

Wir arbeiten mit Screaming Frog, Sitebulb, JetOctopus, Ryte, Sistrix, Ahrefs, Google Search Console und PageSpeed Insights. Werkzeuge liefern Daten — sie ersetzen keine Priorisierung. Die schwierige Arbeit besteht darin zu wissen, welche zehn der dreihundert Funde aus einem Crawler-Report die wirtschaftliche Wirkung tragen.

Häufige Fragen

Spätestens, sobald die Site mehr als ein paar hundert URLs hat, ein Frontend-Framework mit Hydration nutzt, regelmäßig Releases ausspielt oder eine Migration plant. Bei kleinen, statischen Sites reichen oft Basics aus dem CMS heraus.


Wenn Sie wissen wollen, wie tragfähig Ihr technisches SEO-Fundament aktuell ist, ist der SEO-Audit der direkte Einstieg. Wenn Sie den größeren Rahmen sehen wollen, sind das die SEO-Leistungen insgesamt oder die Methode, mit der wir Mandate aufsetzen.