In der Webentwicklung hält sich ein bequemer Mythos: Baue eine schnelle, moderne Website, und das SEO erledigt sich von selbst.
Tut es nicht.
Eine individuell entwickelte Website verschafft Ihnen einen großen Vorsprung — sauberes HTML, schnelle Seiten, kein Plugin-Ballast. Aber Suchmaschinen brauchen trotzdem die richtigen Signale, um zu verstehen, zu vertrauen und einzuordnen, was Sie gebaut haben. Fehlen diese Signale, kann eine wirklich gute Website unsichtbar bleiben.
Das ist die technische SEO-Ebene, die wir in jedes Projekt einbauen. Hier ist der Praxisleitfaden — die Teile, die wirklich etwas bewirken, und ein paar Fallen, die auch gut gebaute Websites erwischen.
Warum eine schnelle Website trotzdem eine technische SEO-Ebene braucht
Wenn Sie auf einem Framework wie Next.js entwickeln, läuft vieles von Haus aus richtig: semantisches Markup, schnelle Ladezeiten, mobilfreundliche Layouts. Das ist das Fundament, das Suchmaschinen belohnen.
Aber „schnell und sauber" ist nicht dasselbe wie „verstanden". Ein Crawler, der auf Ihrer Seite landet, muss Fragen beantworten: Was für ein Unternehmen ist das? Wer hat diesen Artikel geschrieben? Wo steht diese Seite in der Struktur? Ist dieser Inhalt sehenswert? Nichts davon geschieht automatisch — Sie müssen es ausdrücklich sagen, in einer Sprache, die die Maschine liest.
Diese Sprache besteht vor allem aus strukturierten Daten, Sitemaps und Core Web Vitals — plus ein paar Inhalts-Signalen. So gehen wir jeden Punkt an.
Strukturierte Daten: der größte Hebel, den die meisten überspringen
Strukturierte Daten (JSON-LD) sind ein kleiner, maschinenlesbarer Codeblock, der Ihre Seite beschreibt. Sie sind die Grundlage für Rich Results — die Sternebewertungen, FAQ-Aufklappmenüs, Breadcrumb-Pfade und Knowledge-Panel-Details, die Sie bei Google sehen.
Die meisten individuellen Websites liefern davon wenig bis nichts aus. Das ist der größte und einfachste Gewinn, der auf dem Tisch liegt.
Worauf es wirklich ankommt
Sie brauchen nicht jeden Schema-Typ. Konzentrieren Sie sich auf die, die zu echten Seitentypen passen:
- Organization — ein Block, seitenweit. Name, Logo, Kontaktpunkt, Social-Profile und die Regionen, die Sie bedienen. So baut Google eine Entität für Ihr Unternehmen auf.
- WebSite — deklariert die Website und ihre Sprache(n).
- Article / BlogPosting — auf jedem Beitrag: Überschrift, Autor, Veröffentlichungs- und Änderungsdatum, Bild. Das macht Artikel für die reichhaltige Darstellung überhaupt erst geeignet.
- BreadcrumbList — die Hierarchie der Seite (Start › Blog › Dieser Beitrag). Google zeigt sie in den Ergebnissen statt einer nackten URL.
- FAQPage — wenn eine Seite echte Fragen beantwortet, kann das aufklappbare Ergebnisse einbringen.
Zwei Details, die man richtig machen sollte: Verweisen Sie das logo Ihrer Organization auf ein Raster-PNG, nicht auf ein SVG-Favicon (Googles Richtlinien sind hier eindeutig), und stellen Sie sicher, dass Ihre sameAs-URLs wirklich mit Ihren aktiven Profilen übereinstimmen. Eine Abweichung schwächt still und leise die Entität, die Google für Sie aufbaut.
Die Sitemap, die 200 liefert — und trotzdem „nicht abgerufen" werden kann
Das ist die subtilste Falle auf der Liste, und sie erwischt auch gut gebaute Websites — deshalb lohnt sich das Detail.
Stellen Sie sich eine Sitemap vor, die alles richtig macht: Sie liefert 200 OK, gültiges XML, lädt in unter 200 ms, hat ein gültiges Zertifikat und ist nicht durch robots blockiert. Aus jedem Blickwinkel, den Sie testen können, funktioniert sie. Und die Search Console meldet trotzdem „Konnte nicht abgerufen werden."
Die übliche Ursache ist wie sie ausgeliefert wird, nicht ihr Inhalt. Eine Sitemap, die von einer dynamischen App-Route generiert wird, kann mit Framework-spezifischen Caching- und Content-Negotiation-Headern zurückkommen, die Googles Sitemap-Fetcher — ein anderer Mechanismus als der normale Crawler — nicht akzeptiert. Eine Live-URL-Prüfung kann sogar „Seitenabruf: Erfolgreich" zeigen, was es wie einen Fehler der Search Console aussehen lässt.
Die Lösung ist, die Sitemap als einfache statische Datei beim Build zu erzeugen — identischer Inhalt, saubere Header. Sie wird sofort validiert. Und wenn eine bestimmte URL in der Search Console eine „konnte nicht abgerufen werden"-Historie angesammelt hat, veröffentlichen Sie denselben Inhalt unter einer neuen URL und verweisen Sie die robots.txt dorthin.
Die Erkenntnis: Wenn eine Sitemap „nicht abgerufen werden kann", aber überall funktioniert, wo Sie testen, verdächtigen Sie wie sie ausgeliefert wird, nicht ihren Inhalt.
Core Web Vitals und das Gewicht eines einzigen Bildes
Ladegeschwindigkeit ist ein Ranking-Faktor, und es geht vor allem um Bytes. Auf den meisten Websites ist das schwerste Element ein einzelnes Titelbild.
Hier die Falle: Ein detailreicher 2430px-Screenshot kann in der Quelle 879 KB wiegen, und selbst nach der automatischen Optimierung eines Frameworks liegt die größte ausgelieferte Variante bei rund 188 KB. Auf einer Seite, die es nur mit ~1215px darstellt, ist diese Auflösung reine Verschwendung. Verkleinern Sie die Quelle auf 1150px, und jede ausgelieferte Variante fällt auf rund 52 KB — ein Minus von 70 % — ohne sichtbaren Verlust. „Bei Auslieferung optimiert" hilft nichts, wenn die Quelle dreimal größer ist als nötig.
Geben Sie bei der Gelegenheit jedem Hintergrund- und Dekobild explizite width- und height-Angaben. Fehlende Maße sind eine Hauptursache für Layout-Verschiebungen — das lästige Springen beim Laden — was die Core Web Vitals direkt bestrafen.
Inhalts-Signale: Lesbarkeit und Überschriften
Zwei weichere Signale runden die technische Ebene ab.
Lesbarkeit. Automatische Tools markieren Texte, die auf „schwierigem" Niveau lesen. Oft sind die Sätze in Ordnung — es ist der Wortschatz, der dicht mit formellen, mehrsilbigen Wörtern ist. „Nutzen" statt „verwenden", „unter" statt „gemäß", und ein paar lange Nebensätze aufzuteilen hebt den Wert, ohne etwas zu verflachen. Klarerer Text ist besser für Leser und Maschinen.
Überschriften. Ein Mythos, den man ausräumen sollte: Mehrere <h2> auf einer Seite sind kein Problem. Manche Audit-Tools beanstanden es, aber es ist korrektes HTML — jede Seite mit mehr als einem Abschnitt sollte mehr als ein <h2> haben. Wichtig ist eine logische Reihenfolge: ein <h1>, Abschnitte als <h2>, Unterpunkte als <h3>. Überspringen Sie keine Ebenen, und lösen Sie keine echten Abschnitte auf, nur um ein Tool zufriedenzustellen.
Breadcrumbs: Schema und der sichtbare Pfad
Breadcrumbs erfüllen zwei Aufgaben. Das BreadcrumbList-Schema erlaubt Google, den Pfad in den Ergebnissen zu zeigen. Der sichtbare Breadcrumb hilft Nutzern und verstärkt die Hierarchie. Machen Sie beides und halten Sie die URLs kanonisch — ein Breadcrumb, der auf eine weiterleitende URL zeigt, ist eine kleine, vermeidbare Verschwendung.
Die Checkliste
Wenn Sie eine individuelle Website prüfen, hier die Kurzfassung:
- Organization + WebSite JSON-LD, seitenweit, mit Raster-Logo und korrekten
sameAs. - Article-Schema auf Beiträgen, mit
datePublished,dateModified, Autor und Bild. - BreadcrumbList-Schema — plus sichtbarer Pfad — auf verschachtelten Seiten.
- Sitemap als statische Datei ausgeliefert; jeder interne Link zeigt auf kanonische (nicht weiterleitende) URLs.
- hreflang / canonical korrekt auf jeder lokalisierten Seite.
- Bilder: Quelle nicht größer als nötig, explizite
width/height, moderne Formate. - Metadaten: eindeutige Titel unter ~60 Zeichen, Beschreibungen unter ~155.
- Überschriften: ein
<h1>, logische<h2>/<h3>-Struktur. - Robots + Indexierung: sicherstellen, dass wichtige Seiten indexierbar sind und Weiterleitungen sauber auflösen.
Eine individuelle Entwicklung bringt Sie fast ans Ziel — aber die letzte Meile des technischen SEO macht aus einer schnellen Website eine auffindbare. Nichts davon ist glamourös. Alles davon summiert sich.
Es ist die Arbeit, die wir in Projekte einbauen und als eigenständige Audits durchführen. Wenn Ihre individuell entwickelte Website in der Suche still unter ihren Möglichkeiten bleibt, sprechen wir — ein technisches Audit fördert meist eine Handvoll Fixes mit überproportionaler Wirkung zutage.