WPPoland - Neuaufbau einer evidenzbasierten WordPress-, Astro- und technischen-SEO-Website

#WPPoland als öffentlicher Beweis für die Art, wie gearbeitet wird

WPPoland brauchte eine Website, die nicht klang wie eine weitere generische WordPress-Agenturseite. Die eigentliche Einschränkung war einfach: Viele starke Projekte lassen sich nicht direkt zeigen, weil Kundenvereinbarungen Screenshots, Namen, Kennzahlen und Implementierungsdetails einschränken. Die Website kann deshalb nicht ehrlich mit Search-Console-Exporten, Umsatzzahlen oder Kundenlogos argumentieren, solange diese Details nicht ausdrücklich freigegeben sind.

Deshalb wurde die eigene Website zum ersten öffentlichen Evidenzprojekt: welcher Technologiestapel gewählt wird, wie Inhaltsqualität geschützt wird und wie öffentliche Aussagen von Daten unter Vertraulichkeitsvereinbarung getrennt bleiben. Diese Fallstudie beschreibt diesen Neuaufbau, und sie befolgt zugleich die Regel, die sie beschreibt: Sie enthält keine Traffic-, Anfrage- oder Umsatzzahlen, weil es dafür keine datierte, freigegebene Quelle gibt.

#Ausgangspunkt: weniger Behauptungen, sichtbarere Methode

Technische Projekte sind voller leichter Aussagen. “Modernes WordPress”, “Performance”, “SEO”, “KI-fähig” und “Enterprise-Qualität” bedeuten sehr wenig, solange der Leser die Methode dahinter nicht prüfen kann. Der WPPoland-Neuaufbau setzte deshalb darauf, generische Aussagen durch sichtbare Struktur zu ersetzen.

Das bedeutete einige harte Regeln:

• keine Aussagen zu Traffic, Anfragen oder Umsatz ohne datierte Evidenz,
• keine überhöhte Teampositionierung,
• keine generischen Leistungsseiten, die nur ein Menü füllen,
• keine Stadtpläne, die in unbezogene Technologien abdriften,
• keine lokalisierten Texte, die wie englische Syntax mit übersetzten Wörtern klingen.

Das klingt weniger theatralisch als übliche Marketingtexte, und genau darin liegt die Stärke. Ein technischer Einkäufer erkennt in kurzer Zeit, ob die Person hinter dem Projekt weiß, wo die Evidenz endet und die Spekulation beginnt. Diese Unterscheidung ist in einem Markt, in dem jede Agenturseite dieselben Adjektive verwendet, das einzige verlässliche Differenzierungsmerkmal, das eine Website besitzt.

#Architektur: Astro im Frontend, WordPress in der Expertise-Ebene

WPPoland kommuniziert weiterhin tiefe WordPress-Expertise. Gleichzeitig läuft die öffentliche Marketing-Website als statisch zuerst gedachtes Astro-Projekt. Das war keine dekorative Stapelentscheidung. Statische Generierung, Markdown/MDX-Inhalte und ein kontrollierter Build-Prozess passen zu einer großen mehrsprachigen SEO-Website, weil sie jede Route, jedes Metadatenfeld und jede Inhaltsbeziehung prüfbar machen. Was im Repository liegt, ist der Zustand, der gebaut und ausgeliefert wird; es gibt keine zweite Wahrheit in einer Datenbank, die jemand manuell verändert hat.

Das Repository enthält:

• Leistungsseiten,
• Portfolio und Fallstudien,
• lange Fachartikel,
• Stadtpläne,
• Markdown-Varianten für KI-Crawler,
• strukturierte Daten für Organisation, Autor, Leistungen, Artikel, Brotkrumen-Navigation und FAQ.

Damit ist die Website kein Stapel von Landeseiten. Sie ist ein Contentsystem, in dem sich Leistungen, Sprachen, Standorte, Artikel und Evidenzprojekte gemeinsam prüfen lassen. Wenn eine Leistung umbenannt wird, zeigt die Struktur, welche Seiten davon berührt sind. Wenn eine Sprache hinzukommt, zeigt die Struktur, welche Inhalte fehlen, bevor sie veröffentlicht werden. Diese Prüfbarkeit ist der eigentliche Gewinn der Architektur, und sie ist der Grund, warum die Frage “Astro oder WordPress” in dieser Form falsch gestellt ist: WordPress ist hier die Expertise-Ebene, in der das Wissen über WordPress-Entwicklung steckt, und Astro ist die Veröffentlichungsebene, die dieses Wissen ausliefert.

#Sechs Sprachversionen ohne KI-Slop

Die mehrsprachige Veröffentlichung war eines der größten Risiken des Neuaufbaus. Übersetzung allein genügt nicht, weil lokalisierte Seiten schnell unnatürlich klingen. Manchmal zielt der Titel auf eine Technologie, während die unteren Abschnitte eine andere verkaufen. Manchmal besteht die Sprache formal, aber der Rhythmus ist offensichtlich aus dem Englischen importiert.

Der Neuaufbau hat deshalb Lokalisierungs- und Sprachqualitätsprüfungen eingebaut, die Texte erkennen, die zu generisch, zu mechanisch oder vom Seitenthema entfernt sind. In der Praxis heißt das: Eine WordPress-Seite soll nicht plötzlich Next.js verkaufen, weil ein wiederverwendeter Baustein an anderer Stelle davon erwähnt wurde. Für den deutschen Markt heißt es zusätzlich, dass die Texte in der Sie-Form geschrieben sind und dass deutsche Käufer die Prozess- und Verlässlichkeitsinformationen bekommen, die sie erwarten, statt einer wörtlichen Übersetzung eines englischen Textes.

Dasselbe Prinzip gilt für SEO-Überschriften. Der Ausdruck soll suchbar sein, aber der Satz muss klingen wie etwas, das ein Mensch veröffentlichen würde. Eine gute Überschrift führt den Leser. Sie befriedigt nicht bloß eine Schlüsselwortliste.

#Gates, die schwache Veröffentlichung verhindern

Der wichtigste Teil des Neuaufbaus ist nicht visuell. Er ist prozedural. WPPoland hat Prüfungen, die entscheiden, ob Inhalte und Struktur bereit zur Veröffentlichung sind.

Diese Prüfungen decken ab:

• Gültigkeit des Frontmatter,
• Lokalisierungsqualität,
• übergenerische Texte,
• Zitate und Quellensicherheit,
• Abdeckung der Leistungen,
• Konsistenz der Evidenzprojekte,
• Release-Bereitschaft vor größeren Auslieferungsarbeiten.

Das verhindert einen häufigen Fehlermodus: Die Website wächst, aber das Argument wird schwächer. Wenn eine neue Leistung keine Evidenz, kein Briefing, kein Beispiel und keine Veröffentlichungsgrenze hat, soll sie nicht so tun, als wäre sie ein reifes Angebot. Die Gates sind im Build verankert und laufen vor jeder Veröffentlichung; ein Text, der sie nicht besteht, erreicht die Website nicht, unabhängig davon, wer ihn geschrieben hat. Diese Unabhängigkeit von der Person ist wichtig, weil sie die Qualitätsregel vom guten Willen des Augenblicks löst. Übertragen auf ein Kundenprojekt heißt das: Die Prüfungen gehören in die Auslieferungskette und nicht in einen Handbuch-Anhang, den niemand aufschlägt. Ein Gate, das ein Mensch manuell ausführen muss, wird unter Zeitdruck übersprungen; ein Gate, das im Build läuft, ist nicht überspringbar, ohne dass der Build selbst abbricht.

#Technisches SEO und strukturierte Daten

Das technische SEO-Modell dieses Neuaufbaus ist bewusst unprätentiös: Es setzt nicht auf Tricks, sondern darauf, dass jede Seite ihre Maschinenlesbarkeit mitliefert. Strukturierte Daten existieren für Organisation, Autor, Leistungen, Artikel, Brotkrumen-Navigation und FAQ, und sie werden aus denselben Quelldaten erzeugt, aus denen die Seite selbst gebaut wird. Diese Kopplung ist der entscheidende Punkt: Auszeichnung, die von Hand in ein Template geschrieben wird, driftet mit der Zeit von den Inhalten davon; Auszeichnung, die aus dem Frontmatter der Inhalte entsteht, kann nur dann falsch sein, wenn die Inhalte selbst falsch sind, und genau das fangen die Qualitätsgates ab.

Dasselbe Prinzip gilt für die Metadaten. Canonical-Adressen, Sprachverweise und Social-Preview-Felder sind Pflichtfelder im Frontmatter, nicht freiwillige Zusätze. Wer eine neue Sprachversion anlegt, kann eine Seite gar nicht veröffentlichen, ohne die Beziehungen zu den anderen Sprachversionen anzugeben. Das klingt wie Bürokratie und ist in Wahrheit die Antwort auf eine Frage, die jede mehrsprachige Website früher oder später teuer bezahlt: welche Fassung einer Seite die Suchmaschine als maßgeblich behandeln soll, wenn sechs fast gleiche Texte existieren.

#AEO/GEO und Markdown-Varianten für KI-Crawler

Neben der klassischen Suche hat sich eine zweite Leserschaft etabliert: KI-Systeme, die Inhalte nicht als Seiten, sondern als Text und Struktur aufnehmen. Der Neuaufbau berücksichtigt das mit eigenen Markdown-Varianten der Inhalte, die für KI-Crawler gedacht sind, und mit einer Struktur, die Fragen und direkte Antworten trennt. Diese Arbeit heißt im Jargon AEO und GEO, aber der Mechanismus dahinter ist altbekannt: Wer einer Maschine die Antwort in einer Form liefert, die sie ohne Raten verwenden kann, wird korrekt zitiert; wer seine Antwort in ein Layout einschließt, überlässt das Zitat dem Zufall.

Wichtig ist die Grenze, die dabei eingehalten wird: Die Markdown-Varianten sind keine separaten Werbetexte, sondern Fassungen derselben Inhalte, die aus denselben Quelldaten entstehen. Es gibt also keine zweite Wahrheit für Maschinen und keine für Menschen, sondern eine Quelle und zwei Auslieferungsformen. Diese Disziplin verhindert die häufigste Entartung neuer SEO-Felder, nämlich dass ein zusätzlicher Inhaltstyp mit eigenen Texten angelegt wird, der nach einem Jahr niemand mehr pflegt und der dann falsche Aussagen verbreitet.

#Umsetzungsprozess in Phasen

Der Build lief über rund zwölf Wochen und folgte einer klaren Reihenfolge. Die erste Phase gehörte der Positionierung und den Veröffentlichungsgrenzen: Was darf gezeigt werden, was bleibt unter Vertraulichkeit, und welche Aussagen brauchen welche Art von Quelle? Erst danach begann die Inhaltsarchitektur, in der Leistungsseiten, Portfolioeinträge, Fachartikel, Stadtpläne und Markdown-Varianten in einem Repository organisiert wurden. Die dritte Phase baute die Qualitätsgates, und erst die letzte Phase füllte das System mit Inhalten in allen sechs Sprachversionen.

Diese Reihenfolge ist der Unterschied zu einem gewöhnlichen Relaunch. Ein Relaunch beginnt üblicherweise mit einem Entwurf und endet damit, dass die alten Texte in neue Vorlagen kopiert werden, inklusive aller Inkonsistenzen. Dieser Neuaufbau begann mit den Regeln und endete mit Texten, die diese Regeln schon beim Schreiben berücksichtigt haben. Die Verifikation vor dem Launch lief gegen eine Kopie der Produktionsumgebung: Alle Pfade, auf denen Verkehr läuft, wurden dort geprüft und nicht auf einer leeren Installation, weil sich Metadaten, Sprachverweise und strukturierte Daten erst am realen Inhaltsbestand sinnvoll validieren lassen. Die Auslieferung läuft über Cloudflare, und die Build-Kette erzeugt bei jedem Lauf die Fassungen, die danach öffentlich sind.

#Was heute öffentlich gezeigt wird

Diese Fallstudie behauptet bewusst kein Traffic-Wachstum und keine Conversion-Steigerung. Sie zeigt etwas Früheres und Wichtigeres: ein System, das solche Aussagen später nur dann veröffentlichen kann, wenn sie dokumentiert sind.

Die öffentliche Evidenz heute besteht aus:

• der Astro- und Markdown/MDX-Architektur,
• der Organisation der Inhalte in sechs Sprachversionen,
• dem technischen SEO- und strukturierten-Daten-Modell,
• dem AEO/GEO-Ansatz und den Markdown-Varianten,
• den Regeln, die unbelegte Aussagen blockieren,
• der Evidenzstrategie für Arbeit, die unter Vertraulichkeitsvereinbarung steht.

Analysedaten, Search-Console-Daten, Anfragen, Umsatz und vertrauliche Kundenergebnisse bleiben privat, bis es eine klare Entscheidung gibt, sie zu veröffentlichen. Diese Zurückhaltung ist keine Schwäche des Projekts, sondern sein Gegenstand: Die Website zeigt im Betrieb, wie ein Unternehmen aussieht, das nur das behauptet, was es belegen kann.

#Was das für Kundenprojekte bedeutet

Die nützliche Lektion ist direkt: Eine technische Website muss nicht alles zeigen. Sie muss zeigen, was sie verteidigen kann. Wenn ein Projekt vertraulich ist, lässt sich trotzdem die Architektur der Entscheidungen erklären, die Wahl der Werkzeuge, die Risiken, den Qualitätsprozess und den Messplan.

Die eigene Website ist dafür ein brauchbares erstes Beispiel, weil sie geprüft werden kann, ohne einen Kunden preiszugeben. Sie zeigt außerdem, dass moderne WordPress-Arbeit nicht zwingend einen einzigen starren Stapel bedeutet: Hier wurde WordPress zur Expertise-Ebene und Astro zur Veröffentlichungsebene. Für einen Auftraggeber mit ähnlicher Situation - viel Wissen unter Vertraulichkeitsvereinbarung, mehrere Sprachen, hoher technischer Anspruch an SEO und Auslieferung - ist das eine nachvollziehbare Blaupause, deren Teile sich einzeln übernehmen lassen.

Wer ein ähnliches Projekt plant, beschreibt in einem schriftlichen Briefing den aktuellen Stapel, den Zielstapel, das Geschäftsziel, die Sprachen, die Compliance-Grenzen, die bekannten technischen Risiken und das, was nach der Auslieferung öffentlich gezeigt werden darf. Dieses Briefing ist die billigste Investition des gesamten Projekts, denn fast jeder spätere Streit lässt sich auf eine seiner Zeilen zurückführen.

#Übergabe und laufender Betrieb

Auch ein eigenes Projekt hat eine Übergabe, und zwar an den Betrieb der Person, die es betreut. Der laufende Betrieb umfasst den kontrollierten Build-Prozess mit den beschriebenen Gates, die Pflege der strukturierten Daten bei jeder Inhaltsänderung, periodische Prüfungen der Lokalisierung und die Beobachtung, wie KI-Crawler und Suchmaschinen die Markdown-Varianten aufnehmen. Änderungen an der Architektur folgen denselben Regeln wie Inhaltsänderungen: dokumentiert, geprüft und erst nach bestandenen Gates veröffentlicht. Diese Kontinuität zwischen Bau und Betrieb ist der Grund, warum die Veröffentlichungsregeln nach dem Launch nicht erodiert sind.

#Lehren für Auftraggeber

Drei Erkenntnisse aus diesem Neuaufbau lassen sich auf fast jedes technische Webprojekt übertragen. Erstens: Veröffentlichen Sie die Regeln, bevor Sie die Inhalte schreiben. Die Grenze zwischen zeigbar und vertraulich ist eine Architekturentscheidung und keine Textentscheidung am Projektende. Zweitens: Mehrsprachigkeit ist ein Qualitätsproblem, kein Übersetzungsproblem. Wer sechs Sprachversionen mit manueller Kopierarbeit absichert, verwaltet sechs Möglichkeiten, dieselbe Aussage inkonsistent zu machen. Drittens: Ein Stapelwechsel ist dann gerechtfertigt, wenn er eine Prüfaufgabe löst, und nicht dann, wenn er aktuell mode ist.

#Wann dieses Szenario auf Ihr Projekt passt

Dieses Szenario passt zu Ihnen, wenn Sie ein Unternehmen mit starkem technischem Wissen betreiben, das sich wegen Kundenvereinbarungen nicht voll zeigen darf; wenn Sie in mehreren Sprachversionen veröffentlichen und Konsistenz dort wichtiger ist als Veröffentlichungstempo; wenn Sie technische Einkäufer erreichen wollen, die Behauptungen prüfen, statt ihnen zu glauben; und wenn Sie eine Architektur suchen, in der Expertise und Veröffentlichung getrennt wachsen können, etwa WordPress als Wissens- und Betriebsebene mit einer statischen Veröffentlichungsschicht.

Es passt nicht, wenn Sie redaktionelle Abläufe brauchen, die von Nicht-Technikerinnen täglich in einer vertrauten Oberfläche bedient werden müssen, wenn Ihre Inhalte stark personalisiert oder transaktional sind, oder wenn das eigentliche Problem Ihrer Website nicht die Architektur ist, sondern das Fehlen eines klar formulierten Angebots. Ein Umbau, der nur an der Oberfläche ansetzt, löst keine dieser Fragen.

Wenn Sie einen Neuaufbau oder eine Architekturumstellung planen, schildern Sie den aktuellen Stapel, das Geschäftsziel, die Sprachen und die Veröffentlichungsgrenzen. Wir antworten mit einer ehrlichen Einschätzung, ob eine Umstellung Ihr Problem löst oder ein kleinerer Schritt genügt. Erreichen Sie uns über unsere deutsche Kontaktseite, und der erste Termin kostet Sie nichts als eine klare Aufgabenbeschreibung.