WordPress mit KI-Agenten bauen: Prüfen ist die Arbeit

Diese Website ist mit WordPress und Elementor gebaut worden, bedient von Claude Code, angebunden über Novamira. Wer heute WordPress mit KI-Agenten bauen lässt, erlebt dabei etwas anderes, als die Werbung für solche Werkzeuge verspricht. Das Änderungsprotokoll dazu ist für den 23. bis 25. August 2026 lückenlos.

Der Seitenbaum stand an einem Tag.

Die beiden Tage danach gingen fast vollständig dafür drauf, nachzuprüfen und Fehler zurückzunehmen, die beim Bauen entstanden waren.

Das ist kein Anlaufverlust.

Das ist die Verteilung.

Die These, in einem Satz: Ein Werkzeug, das Seiten erzeugt, spart keine Arbeit, es verschiebt sie vom Schreiben ins Prüfen.

Wer die Prüfstrecke nicht mitbestellt, bekommt eine Website mit Fehlern, die er selbst nicht mehr findet, weil sie an Stellen sitzen, die er nie ansieht.

Drei dieser Stellen im Einzelnen.

Eine Prüfung, die der Sitemap folgt, sieht die halbe Website

Die Sitemap führt veröffentlichte Seiten.

In WordPress steht das im Quelltext: WP_Sitemaps_Posts fragt mit post_status => array( ‚publish‘ ) ab.

Für eine Suchmaschine ist das richtig.

Für eine Prüfliste ist es der falsche Ausgangspunkt.

An einem einzigen Tag ist uns das mehrfach aufgefallen.

Eine Prüfung der Bildunterschriften zählte vierzehn Stück und übersah eine Seite mit zwei weiteren, weil die Seite auf Entwurf stand.

Ein Beitrag, ebenfalls Entwurf, rutschte durch zwei aufeinanderfolgende Prüfdurchgänge: Beide prüften gegen die gerenderte Seite, und ein Entwurf liefert 404. So blieb unbemerkt, dass das Erzeugungsskript am Ende zwei Korrekturen enthielt, die in der Beitragsvorlage fehlten.

Und acht Bibliotheksvorlagen trugen elf Bildunterschriften auf einem älteren Stand.

Bibliotheksvorlagen sind der unangenehmere Fall.

Sie sind unter keiner Adresse abrufbar, aber der Seitenaufbau greift auf sie zurück.

Wer die Seite korrigiert und die Vorlage stehen lässt, hat eine Korrektur, die bis zum nächsten Neuaufbau hält.

Die Prüfliste kommt deshalb aus der Datenbank und nicht aus der Sitemap: alle Seiten, alle Entwürfe, alle Bibliotheksvorlagen.

Wer die Seite korrigiert und den Generator nicht, hat nichts korrigiert

Die Beiträge dieser Website entstehen aus einem Skript.

Das ist die Voraussetzung dafür, dass ein Werkzeug überhaupt schnell arbeiten kann: Es gibt eine Quelle, und aus ihr fällt die Seite heraus.

Genau das schlägt zurück, sobald jemand am anderen Ende korrigiert.

Am 24. August stehen fünf Protokolleinträge zu derselben Sache.

Die Website war von internen Arbeitsvermerken frei, das erzeugende Skript trug noch neunzehn.

Verkürzte Urhebernennungen, auf den Seiten längst richtiggestellt, waren im Skript fest verdrahtet.

Und die Funktion, die Bildunterschriften baut, erzeugte weiterhin die Fassung von vor der Korrektur.

Ein einziger Lauf hätte bei allen sechzehn Bildunterschriften den Lizenzlink und den Bearbeitungshinweis wieder entfernt.

Keiner dieser Fehler wäre beim Ansehen der Website aufgefallen.

Sie wären Wochen später zurückgekommen, alle auf einmal, und niemand hätte den Zusammenhang gesehen.

Nach jeder Korrektur an einer Seite gehört deshalb die Frage dazu, welches Skript diese Stelle erzeugt.

Gibt es eines, ist die Korrektur dort noch nicht gemacht.

Das kostet jedes Mal ein paar Minuten und ist der einzige Grund, warum die Korrekturen dieser drei Tage heute noch stehen.

Ein Befund „fehlt“ gilt erst, wenn jemand hingesehen hat

Zwei Befunde einer Prüfung waren schlicht falsch.

Sie behaupteten, die Formulare erhöben personenbezogene Daten ohne den Hinweis nach Artikel 13 DSGVO.

Der Hinweis stand zu diesem Zeitpunkt bereits an beiden Formularen, unmittelbar über dem Absenden-Button.

Wie es dazu kam: Die Prüfung suchte im ausgelieferten Quelltext nach Stichworten.

Die JSON-Payload des Einwilligungsbanners schwemmte die Trefferliste voll, und die Ausgabe war auf die ersten Zeilen begrenzt.

Der Formularhinweis stand weiter unten.

Ein Blick auf das Formular hätte den Befund sofort widerlegt.

Es geht auch andersherum.

Dasselbe Einwilligungsbanner war während des Aufbaus unsichtbar.

Sein JavaScript stürzte beim Aufbau ab, weil drei Abstandswerte als Zeichenkette statt als Zahlenliste in der Datenbank standen.

Im Quelltext war davon nichts zu erkennen: Das Markup war da, der Verweis „Cookie-Einstellungen“ in der Fußzeile war anklickbar, und es passierte nichts.

Sichtbar wurde der Absturz erst in der Browser-Konsole.

Und dann das Messwerkzeug selbst.

Es meldete für eine Seite einen LCP von 4,07 Sekunden.

Die Ursache lag im eigenen Ablauf: Der Full-Page-Screenshot entstand vor der Messung.

In diesem Moment zeichnet der Browser zum ersten Mal alles unterhalb des ersten Bildschirms, und jeder große Absatz dort meldet sich als neuer Kandidat, mit dem Zeitstempel des Screenshots.

Gegenprobe: derselbe Aufruf ohne Screenshot 1116 Millisekunden, mit Screenshot 4220.

Derselbe Ablauf log auch in die andere Richtung.

Zwei Bilder standen im Screenshot als weiße Fläche und wurden für kontrastschwach gehalten.

Sie waren in Ordnung.

Ein Bild mit loading=“lazy“ wird erst geladen, wenn es in die Nähe des Sichtfelds gerät. Der Full-Page-Screenshot zeichnet den Bereich darunter zwar mit, verschiebt das Sichtfeld selbst aber nicht. Das Bild bleibt ungeladen, und an seiner Stelle bleibt die Fläche weiß.

Aufgefallen ist es erst bei einem mittelgrauen Foto, bei dem ein Kontrastproblem ausgeschlossen war.

Die Regel, die wir daraus gemacht haben, ist unbequem: Ist ein Befund falsch, wird das Werkzeug geändert und nicht die Seite.

Falsch-positive sind schlimmer als fehlende Regeln, weil danach niemand mehr hinsieht.

Wo die Werkzeuge wirklich verdient haben

Der ehrliche Teil in die andere Richtung, und er ist kurz.

Ein Werkzeug liest Ressourcenlisten schneller und geduldiger als ein Mensch.

Auf dieser Website lag Ballast: Unsere Dequeue-Liste für ungenutzte Stylesheets nannte die falschen Handles und hatte deshalb nie gegriffen.

Nach der Korrektur auf der Startseite acht Anfragen weniger, sieben davon render-blockierend, 31 KiB. jQuery lag render-blockierend im <head> und wanderte in den Footer, weitere 34 KiB.

Elementor hat 2021 selbst beschrieben, warum ungenutzte Widget-Dateien auf einer Seite nichts verloren haben.

Das Prinzip war bekannt, der Fehler saß in unserer eigenen Liste.

Dazu der Seiten-Cache: Zeit bis zum ersten Byte von 667 auf 22 Millisekunden.

Heute liegt der LCP auf allen öffentlichen Seiten zwischen 0,86 und 1,12 Sekunden, der CLS bei null.

Warum die Schriften dabei lokal liegen und was daran trotzdem schiefgehen kann, steht in einem eigenen Beitrag.

Vergleichen, dreimal messen, nicht müde werden: Das ist die Sorte Arbeit, in der ein Werkzeug einen Menschen schlägt.

Die Reihenfolge, die daraus geworden ist

• Die Quelle festlegen, bevor gebaut wird. Bei uns ist es der Projektordner und nicht die Datenbank. Jede Korrektur geht zuerst dorthin.

• Die Prüfliste aus der Datenbank ziehen, nicht aus der Sitemap. Entwürfe und Bibliotheksvorlagen gehören hinein.

• Nach jeder Korrektur den Generator nachziehen. Sonst hält sie bis zum nächsten Lauf.

• Jeden Befund „fehlt“ ansehen. Ein Textfilter, dessen Ausgabe abgeschnitten ist, beweist nichts.

• Nach jeder Änderung an JavaScript die Browser-Konsole öffnen. Der Quelltext zeigt einen Absturz nicht an.

• Das Messwerkzeug gegen sich selbst prüfen. Einmal mit Screenshot, einmal ohne. Weichen die Werte ab, misst es sich selbst.

• Nichts, was Regeln neu schreibt, aus der Kommandozeile aufrufen. flush_rewrite_rules() ist das Beispiel: Der Zeitpunkt entscheidet, und wer ihn verfehlt, schreibt einen unvollständigen Stand und bekommt dabei eine Erfolgsmeldung.

Was hier nicht steht: die Sicherheitseinstellungen dieser Installation im Einzelnen.

Gehärtet wurde in den üblichen Kategorien, von den HTTP-Headern bis zur gesperrten Benutzerabfrage über die REST-API.

Was davon wo greift, gehört nicht in einen öffentlichen Text.

Und die Grenze der These: Sie gilt für Websites, die aus Vorlagen erzeugt werden.

Wer seine zehn Seiten von Hand im Editor tippt, hat keinen Website-Generator und damit auch dessen Problem nicht.

Er hat dafür auch keine wiederholbare Herstellung, und die nächste Umstellung fängt wieder bei null an.

Das ist ein Tausch und kein Fortschritt in eine Richtung.

Der Vergleich, um den es geht, heißt deshalb nicht Werkzeug gegen Mensch.

Er heißt Werkzeug mit Prüfstrecke gegen Werkzeug ohne.

Wer nur die erste Hälfte kauft, kauft Geschwindigkeit bis zum ersten Befund.

Belege

Belege zuletzt geprüft am 25. August 2026.

• WordPress Developer Resources, Klasse WP_Sitemaps_Posts

• WordPress Developer Resources, flush_rewrite_rules()

• Elementor Developers: How Elementor Improved Asset Loading and Made Your Website Run Faster, 11. Juli 2021

• Chrome DevTools Protocol, Page domain, dort Page.captureScreenshot mit captureBeyondViewport

• MDN Web Docs, <img>, Attribut loading

Alle Messwerte in diesem Text stammen aus eigenen Messungen an phiec.de vom 25. August 2026: Ladezeiten mit Lighthouse und den Entwicklerwerkzeugen des Browsers im Desktop-Profil ohne Drosselung, je drei Durchläufe, die Zeit bis zum ersten Byte als Median aus zehn Aufrufen.

Alle Stückzahlen stammen aus dem internen Änderungsprotokoll zum Aufbau dieser Website, Einträge vom 23. bis 25. August 2026, ausgewertet am 25. August 2026.