Damit der Googlebot keine Zugriffe auf Unwichtiges verschwendet
Parameter-Wildwuchs, facettierte Duplikate, Soft 404s und endlose Archive. Logs und Crawl-Daten zeigen, wohin das Budget tatsächlich fließt.
WordPress · Crawl · Index · Architecture
Crawl-Budget
Indexation
Architektur
Schema
Performance
Technisches SEO für WordPress direkt im Code umgesetzt.
Ich arbeite als technischer SEO-Berater und WordPress-Entwickler: Ich prüfe und implementiere die Ebene, die dafür sorgt, dass die richtigen URLs gefunden, gerendert, indexiert und verstanden werden — Crawl-Pfade, Canonicals, Sitemaps, interne Architektur, Schema, Redirects, JavaScript-Rendering und Core Web Vitals. Das Ergebnis ist nicht nur ein PDF; die Korrekturen können direkt im Code umgesetzt werden.
Nur die URLs, die wirklich konkurrieren sollen
Klare Canonicals, diszipliniertes noindex, ehrliche Sitemaps und Bereinigung dünner oder doppelter Templates, die Rankings verwässern.
Interne Pfade, die Linkkraft weitergeben
Hub-Struktur, Pagination und Links, die wichtige Seiten auffindbar machen, ohne ausschließlich von der Homepage abzuhängen.
Structured Data, die zur Seite passen
Valide Graph-Markups für Entitäten, die tatsächlich auf der Seite vorkommen – kein Auto-Schema, das Rich-Result-Tests nicht besteht.
CWV als Ranking-Grundlage
Technisches SEO umfasst auch den Renderpfad, wenn Feldmetriken wettbewerbsrelevante Queries blockieren.
Technisches WordPress-SEO: Beratung + Umsetzung
Die technischen Bedingungen beheben, die bestimmen, welche Seiten Google vertrauen und abrufen kann.
WordPress ist flexibel genug für eine ausgezeichnete Sucharchitektur – und flexibel genug, um doppelte Archive, Parameterfallen, widersprüchliche Canonicals und Schema aus drei verschiedenen Plugins zu erzeugen. Die Arbeit darunter macht daraus ein konsistentes System.
Robots, Statuscodes und Crawl-Pfade
Geblockte Assets, Redirect-Ketten, Soft 404s, Crawl-Fallen und Parametermuster finden, die Discovery verschwenden. Wichtige Seiten sollten über crawlbare HTML-Links erreichbar sein, nicht nur über Sitemap oder JavaScript-Event.
Canonicals, Noindex und korrekte Sitemaps
Canonical-Tags, Index-Direktiven und XML-Sitemaps so ausrichten, dass Google eine konsistente Antwort darauf erhält, welche URL konkurrieren soll. Dünne Archive, Staging-Leaks und doppelte Template-Varianten bereinigen.
Interne Verlinkung, Paginierung und verwaiste Seiten
Crawl-Pfade rund um kommerzielle und redaktionelle Hubs aufbauen, tiefe Seiten mit echtem Sichtbarkeitspotenzial stärken und Pagination oder Facettennavigation so gestalten, dass kein indexierbarer Noise entsteht.
Schema, das zu den sichtbaren Inhalten passt
JSON-LD für Seitentypen implementieren und validieren, die tatsächlich davon profitieren, widersprüchliche Graphen entfernen und Organisation-, Artikel-, Produkt-, Breadcrumb- oder Service-Entitäten intern konsistent halten.
Redirect-Mapping und Absicherung beim Launch
Ranking-Signale bei Domain-, Permalink-, Taxonomie- oder Plattformänderungen mit Redirect-Maps, Canonical-Prüfungen, Sitemap-Updates und Post-Launch-Crawl-Monitoring erhalten, statt Verluste erst Wochen später zu entdecken.
JavaScript-SEO und Performance dort, wo sie Retrieval beeinflussen
Durch Scripts gerenderte Inhalte, lazy-geladene Links, blockierte Ressourcen und Core Web Vitals auf organischen Templates prüfen. Technisches SEO wird praktisch, wenn Rendering oder Performance verhindert, dass eine Seite konkurrenzfähig ist.
Was ich in einem WordPress-Technical-SEO-Audit prüfe
Start mit dem, was Google tatsächlich crawlt und indexiert, und dann zurück zur WordPress-Regel, die es erzeugt hat.
Das Audit vergleicht Search Console, Crawl-Daten, Sitemap-Inventar und – wo verfügbar – repräsentative Serverlogs. Von dort mappe ich das Problem auf Themes, Plugins, Rewrite-Regeln, Taxonomie-Konfiguration, Mehrsprachigkeitslogik, Pagination, Filter oder individuelle Templates.
Das ist wichtig, weil dasselbe Symptom sehr unterschiedliche Ursachen haben kann. Tausende ausgeschlossene URLs können harmlose Aufräumarbeit sein – oder sie zeigen facettierten Crawl-Waste, einen Canonical-Bug, ein Staging-Domain-Leak oder interne Links auf URLs, die nie indexiert werden sollten.
- Indexierung in der Search Console, Crawl-Statistiken, gewählte Canonicals und Sitemap-Abdeckung.
- HTTP-Statuscodes, Redirect-Ketten, Soft-404s und alte URL-Muster.
- robots.txt, Meta-Robots, X-Robots-Tag und umgebungsspezifische Regeln.
- Kategorien, Schlagwörter, Autoren, Datumsarchive, Suche, Filter, Parameter und andere von WordPress erzeugte Archive.
- Interne Links, Breadcrumbs, Pagination, verwaiste Seiten und Klicktiefe zu Money Pages.
- Canonical-Tags, hreflang wo relevant, Structured Data und Signale doppelter Templates.
- JavaScript-Rendering, Core Web Vitals und Unterschiede mobiler Templates auf organischen Landingpages.
WordPress-typische Fehlerquellen
Das SEO-Plugin ist nur eine Ebene.
Yoast, Rank Math oder SEOPress können nützliche Felder bereitstellen, aber sie entwerfen nicht deine Website-Architektur. Die teuren Probleme liegen meist eine Ebene tiefer – in Routing, Templates, Taxonomie, Plugin-Verhalten oder der Art, wie interne Links erzeugt werden.
Tag-, Autoren- und Datumsarchive, die mit echten Landingpages konkurrieren
Entscheiden, welche Archivtypen Suchwert haben, den Rest konsolidieren und interne Linksignale entfernen, die weiterhin dünne oder doppelte Routen stärken.
Filter, die nahezu unendliche Crawl-Kombinationen erzeugen
Festlegen, welche Kombinationen indexiert werden sollen, welche crawlbar aber noindex bleiben und welche überhaupt nicht erzeugt oder verlinkt werden sollten.
Widersprüchliche Canonicals, Schema- und Sitemap-Ausgaben
Mehrere SEO-, E-Commerce- und Schema-Plugins können überlappende Signale ausgeben. Graph und Header werden auf eine konsistente Source of Truth reduziert.
Seiten, die unterschiedlich aussehen, aber denselben SEO-Footprint ausgeben
Headings, Body-Struktur, interne Links, Structured Data und Metadaten auf Template-Ebene prüfen, damit skalierbarer Content nicht zu skalierbarer Duplizierung wird.
Permalink- oder Taxonomieänderungen ohne Signal-Erhalt
Alte URLs vor dem Launch mappen, Redirect-Ketten vermeiden und Canonical- sowie Sitemap-Ausgabe direkt nach der Änderung prüfen.
Sprachrouten und hreflang, die sich widersprechen
Bei mehrsprachigem WordPress Self-Canonicals, reziprokes hreflang, Default-Language-Routing und Sitemap-Abdeckung prüfen, damit regionale Seiten sich nicht gegenseitig kannibalisieren.
Umsetzung statt Audit-Theater
Derselbe Senior-WordPress-Engineer findet das Problem und setzt den Fix um.
Ich arbeite über Entwicklung, Performance und Technical SEO hinweg. Deshalb kann ein Crawl-Problem bis in PHP, Templates, Rewrite-Regeln oder JavaScript verfolgt werden, ohne das Ticket an ein anderes Team weiterzugeben. Wenn der eigentliche Engpass Content-Qualität, Links oder Search Intent statt die Plattform ist, sage ich das ebenfalls.
15+ yearsTiefe Erfahrung mit der WordPress-Plattform.
60+ sitesAusgelieferte oder betreute WordPress-Websites.
+180%Organischer Traffic bei einem repräsentativen WooCommerce-Rebuild mit Taxonomie-Überarbeitung.
Code + SEOAudit-Findings können direkt umgesetzt werden, statt bei Empfehlungen zu enden.
Deliverables
Eine Technical-SEO-Roadmap mit konkreten Fixes.
Du bekommst genügend Evidenz, um das Problem zu verstehen, genügend Priorisierung für Entscheidungen und eine Umsetzung, die sicher durch Staging und Produktion gehen kann.
Crawl- + IndexierungskarteWas Google entdecken kann, was indexiert wird, was ignoriert wird und wo Signale kollidieren.
Priorisierte ProblemlisteKritische, hohe und niedrigere Findings, jeweils den betroffenen Templates oder URL-Mustern zugeordnet.
Umsetzung in Code/KonfigurationCanonicals, Robots-Direktiven, Redirects, Sitemaps, Templates, Schema und Linklogik, wo erforderlich.
MigrationsbegleitungRedirect-Mapping, Launch-Checks und Post-Release-Crawl-Validierung für URL- oder Plattformänderungen.
VerificationRe-Crawl und Search-Console-Checks nach dem Deployment, damit Fixes bestätigt statt nur angenommen werden.
Leitplanken für Redaktion/EntwicklungKurze Regeln für zukünftige Templates, Filter, Kategorien und Releases, damit dasselbe Problem nicht zurückkehrt.
So läuft die Zusammenarbeit
Zuerst den Index diagnostizieren, dann das System ändern.
Analyse
Evidenz vor Empfehlungen
Crawl-Samples, Search-Console-Coverage, Sitemap-vs-Index-Delta, repräsentative Log-Fenster und Template-Inventar. Findings nach Business-Impact priorisiert, nicht nach Länge der Checkliste.
- Aufgeblähter Index und verwaiste URLs
- Regeln für Facetten und Parameter
- Duplikatrisiko auf Template-Ebene
- Schema-Lücken oder ungültige Knoten
Implementation
Fixes in Code und Konfiguration
robots und Header, Rewrite-Regeln, Template-Conditionals, Sitemap-Generierung, Internal-Link-Blöcke und Monitoring, damit der nächste Content-Drop keine alten Lücken wieder öffnet.
- Staging → Produktion with verification
- Dokumentation für Redaktion und Entwickler
- Optionale laufende Crawl-Checks
FAQ
Technisches SEO questions.
Technical SEO umfasst die Infrastruktur, die es Suchmaschinen ermöglicht, die richtigen WordPress-URLs zu entdecken, zu rendern, zu verstehen und zu indexieren. Typische Arbeit umfasst Crawlability, Indexierung, Canonicals, Sitemaps, Redirects, Internal Linking, Schema, JavaScript-Rendering und Core Web Vitals.
SEO-Plugins stellen nützliche Controls bereit, entwerfen aber nicht deine URL-Architektur, lösen keine Crawl-Fallen, entscheiden nicht, welche Facetten indexierbar sein sollten, beheben keine Template-Duplikation, mappen keine Migrationen und reparieren keine widersprüchlichen Ausgaben von Themes und Plugins. Diese Entscheidungen erfordern Site-Level-Engineering.
Beides. Das Audit liefert einen priorisierten Backlog mit Evidenz, und ich kann die Fixes in WordPress-Code und -Konfiguration über Staging, Produktions-Deployment und Verifikation umsetzen.
Logs sind besonders nützlich auf größeren Websites, E-Commerce-Katalogen, Publisher-Seiten und Websites mit vielen Templates oder Parametern. Sie zeigen, welche URLs Googlebot tatsächlich anfragt, und machen Crawl-Waste, Redirect-Loops und Low-Value-URL-Muster sichtbar.
Nein. Technical SEO beseitigt Barrieren und konsolidiert Signale, aber Rankings hängen auch von Search Intent, Content-Qualität, Wettbewerb, Links, Marke und weiteren Signalen ab. Wenn die Plattform gesund ist und der Engpass Content oder Autorität heißt, sollte die Empfehlung genau das widerspiegeln.
Teile Search-Console-Coverage und deine wichtigsten Templates.
Ich sage dir, ob der Engpass Crawl, Indexierung, Architektur ist – oder etwas, das Content noch lösen muss.
Architektur- & Plattformentscheidungen
Technical SEO wird teuer, wenn sich die Architektur erst nach dem Launch ändert.
Diese Vergleiche und Performance-Guides helfen zu entscheiden, ob der aktuelle WordPress-Stack einen Fix, ein Redesign oder eine andere Frontend-Architektur braucht.
AI searchGenerative Engine Optimization (GEO)KI-Sichtbarkeit, zitierte Quellen und zitierfähige Inhalte neben dem SEO messen.PlatformWordPress vs WebflowSEO-Kontrolle, Content-Modellierung, Performance und Ownership.ArchitekturWordPress vs Next.jsKlassisch vs. headless: Rendering, CMS-Workflow und betriebliche Komplexität.PerformanceEine langsame WordPress-Website schneller machenImplementierungs-Altlasten ausschließen, bevor wegen Performance replatformed wird.SucherlebnisWordPress Core Web VitalsEchte Performance work for ranking-critical templates.ServiceWordPress-Performance-OptimierungVolle Performance-Diagnose, wenn das Problem mehrere Ebenen betrifft.EntwicklungWordPress-Entwickler BarcelonaIndividuelle Umsetzung, wenn SEO-Änderungen Code statt nur Empfehlungen benötigen.
