VeloCore – Dokumentation für Redaktionen, Verlage und IT-Abteilungen

Artikel und Seiten werden in WordPress gepflegt. VeloCore erzeugt daraus veröffentlichungsfähige Daten. Das reguläre VeloCore-Frontend kann auf diesen vorbereiteten Daten aufsetzen; bei aktivem Fast-Path entfällt für passende Aufrufe zusätzlich die dynamische HTML-Erstellung.

VeloCore verfolgt ein hybrides Headless-Modell: WordPress bleibt für Redaktion und Verwaltung erhalten. Das öffentliche Theme nutzt einen eigenen Routing- und Rendering-Pfad. Gewöhnliche WordPress-Frontend-Hooks sind daher nicht automatisch kompatibel. Eine bewusst aktivierbare WordPress-Nachladeoption existiert, kann aber den Performance- und Sicherheitsvorteil reduzieren.

Redaktion, Seitenaufbau, visuelle Gestaltung, Menüs, URL-Basen, Archivlayout, Medienqualität, Sprachvarianten, Werbeplätze, Such- und Metadaten sowie verschiedene Interaktionen sind administrierbar. Zusätzliche Module können Layoutbereiche, Content-Typen und die Ausgabe ergänzen.

Besonders geeignet für Nachrichtenportale, Fachmagazine, Verlagstitel und Websites mit hohen Aufrufzahlen, vielen Artikeln oder wechselnden redaktionellen Anforderungen. Ob eine konkrete Integration vollständig ohne dynamische Backend-Aufrufe betrieben werden kann, hängt von deren Funktionen ab.

Im WordPress-Backend unter Werkzeuge → VeloCore Fast Path die statische Apache-Auslieferung aktivieren. Der Bereich prüft die Regelinstallation und ihre Reihenfolge. Anschließend die öffentliche URL einer erstellten Seite mit einem HEAD-Request kontrollieren: X-VeloCore-Fast-Path: 1 zeigt die direkte Auslieferung an. Die Admin-Prüfung allein bestätigt noch nicht den kompletten öffentlichen Proxy-/Webserverweg.

Ein Full Rebuild ist direkt im Fast-Path-Adminbereich auslösbar. Er verarbeitet die Dokumente in kleinen Batches und zeigt Fortschritt, Gesamtsumme, Fast-Path-/Original-/Fehler-Zähler, Dauer und Dokumentprotokoll. Er lässt sich stoppen und fortsetzen. Dafür muss während des browsergesteuerten Vollaufbaus die Administrationssitzung offen bleiben.

Beim Speichern eines veröffentlichten Beitrags wird die betroffene HTML-Ausgabe einschließlich erkannter direkter Abhängigkeiten aktualisiert. Seit vc13 erfolgt dies auch ohne offen gehaltenen Admin-Browser oder WP-Cron. Änderungen an globalen Einstellungen, Design, Menüs und Term-Metadaten können größere Bereiche betreffen und werden über den entsprechenden Admin-/Rebuild-Weg verarbeitet.

Die Engine berücksichtigt gespeicherte Beziehungen. Verweise auf verwandte Artikel folgen dem tatsächlichen, veröffentlichten Related-Posts-Graphen. Die bloße gemeinsame Kategorie löst keine massenhafte Neuerstellung aller Beiträge aus; Kategoriebezeichnungen und Slugs unterliegen eigenen Aktualisierungsregeln.

Schlägt die Neuerzeugung eines Dokuments fehl, wird der betroffene Fast-Path-Eintrag nicht als gültige veraltete Seite weiterbetrieben. Der Aufruf folgt dann dem vorhandenen Originalrouting. Fehler und letzte Entscheidungen lassen sich im Adminbereich prüfen. Dies ist ein definierter Fallback, jedoch keine Garantie, dass jede individuelle Installation identisch konfiguriert ist.

Im Runtime-Adminbereich ist die Zahl aufzubewahrender Generationen einstellbar (2 bis 20). Ein unterbrochener vollständiger Aufbau kann fortgesetzt werden. Die Verwaltung trennt den statischen Veröffentlichungsbestand vom redaktionellen WordPress-Betrieb.

Eine Schutzoption schließt Dokumente mit Same-Origin-POST-Formularen vom Fast-Path aus. Funktionen wie Checkout, geschützte Sitzungen und hochdynamische Personalisierung müssen im konkreten Projekt ausdrücklich geprüft und gegebenenfalls über den nichtstatischen Weg bedient werden.

Ein separat zuschaltbarer Testmodus erlaubt den Vergleich mit einer Auslieferung ohne Fast-Path-Treffer auf Apache-Ebene. Er ist für zeitlich begrenzte Messungen gedacht, nicht für den redaktionellen Regelbetrieb.

Inhalte werden in WordPress erstellt, bearbeitet und veröffentlicht. VeloCore hält die für die öffentliche Ausgabe relevanten Datensätze als vorbereitete Artefakte bereit. Änderung, Zurücknahme und Löschung können die veröffentlichten Artefakte und URL-Zuordnung entsprechend aktualisieren.

Unterstützt werden unter anderem Titel, redaktioneller Vorspann/Anriss, Fließtext, Beitragsbild, Bildunterschrift und Credit, Autor, Datum, Aktualisierung, Kategorien, Schlagworte und verwandte Beiträge. Die tatsächlich ausgegebenen Elemente hängen vom gewählten Template und den belegten Feldern ab.

Eigene Archivseiten für Kategorien, Tags und Autoren sowie Pagination sind vorgesehen. Die URL-Basen für Kategorien und Tags lassen sich einstellen. Archivdarstellungen können zwischen Mix, Liste und Kacheln gewählt werden.

Startseiten lassen sich aus konfigurierbaren Abschnitten zusammensetzen. Beiträge können nach Kategorien, Tags und weiteren Sektionseinstellungen gefiltert, sortiert und limitiert werden. Abhängige Newslisten können nach Inhaltsänderungen aktualisiert werden.

Verschiedene Startseiten lassen sich zeitabhängig einsetzen – etwa nach Wochentagen, Monaten oder festgelegten Datumsspannen. Die operative Planung bleibt administrierbar, ohne dafür Templates auszutauschen.

Für nicht öffentliche Inhalte stehen geschützte Vorschauwege zur Verfügung. Die öffentliche Artefakt-Auslieferung wird vom Vorschauzugriff getrennt; Entwürfe sollen nicht wie veröffentlichte Inhalte behandelt werden.

View-Zählung und entsprechende Artikelstatistiken können in Darstellungen einfließen. Ein optionaler Empfehlungs-Hinweis kann beliebte Artikel anzeigen, konfigurierbar etwa nach Gesamtaufrufen oder 7-Tage-Aufrufen sowie Kategorie- oder Schlagwortbezug.

Die Darstellung von Kommentaren in Artikeln ist global aktivierbar. Passende öffentliche Kontakt-/Kommentar-Endpunkte und Challenge-Verfahren sind vorhanden. Für die tatsächliche Verarbeitung sind die projektspezifischen Einstellungen und Datenschutzanforderungen zu beachten.

Im Pagebuilder einen Sektionstyp auswählen, mit dessen Inhalten befüllen und die Reihenfolge festlegen. Sektionen lassen sich unabhängig voneinander aktivieren, deaktivieren und konfigurieren. Die Vorschau einzelner Sektionen erleichtert die Kontrolle.

Viele Sektionen unterstützen Sichtbarkeitsregeln nach Wochentag, Monat, Datumsbereich und Uhrzeit. So können etwa saisonale Teaser oder zeitlich begrenzte Kampagnen vorbereitet werden.

Pro Sektion sind unter anderem Containerbreite, Layout, Bild-/Video-/Farb-/Verlaufshintergrund, Textmodus, Overlay, Innenabstände und mobile Mindesthöhe konfigurierbar. Die genauen Optionen variieren je Sektion.

Komplette Seitenkonfigurationen können als Pagebuilder-Vorlagen gesichert, auf andere Seiten geladen oder als JSON ausgetauscht werden. Layout-Presets dienen der Wiederverwendung von Sektionseinstellungen.

Tabs, Akkordeons und Tabellen ermöglichen umfangreiche Informationen mit klarer Benutzerführung. Die Tabellentexte sind editierbar und die Tabelle kann mit Rahmen, Zebra-Stil oder kompakter Darstellung versehen werden.

Der Pagebuilder bringt Funktionen zur Prüfung bzw. Nachbesserung von Inhaltsqualität mit, etwa beim Umgang mit Alt-Texten. Die konkrete Ausgabe sollte redaktionell und auf Mobilgeräten kontrolliert werden.

Erweiterungen können eigene Sektionstypen samt Editor, Speicherung, Frontend und Gestaltung bereitstellen. Solche Sektionen sind in der Bauoberfläche integrierbar, sofern das jeweilige Plugin die VeloCore-Schnittstellen implementiert.

Der Design-Manager gliedert die Gestaltung in Bereiche wie Header, Navigation, Startseite, Archive, Artikel, Cards, Buttons, Footer und Pagebuilder-Sektionen. Bereiche können unabhängig bearbeitet werden, ohne das Theme selbst verändern zu müssen.

Primär-, Sekundär- und Akzentfarben, Schatten und weitere Designwerte stehen zentral zur Verfügung. Mehrere Schriftfamilien sind enthalten; eigene Schriften lassen sich hochladen. Überschriften- und Fließtextschrift sind getrennt steuerbar.

Styles können über die Designoberfläche gepflegt und als Konfiguration übernommen oder exportiert werden. VeloCore erstellt daraus die für die Auslieferung benötigten Styles. Bei großen Projekten empfiehlt sich eine geregelte Freigabe und Sicherung der Designstände.

Der Design-Manager enthält eine optionale KI-Unterstützung zur Erstellung bzw. Bearbeitung von Styles anhand von Vorgaben. Generierte Vorschläge sollten vor der Übernahme visuell geprüft werden. API-Zugang, Modellverfügbarkeit und Nutzungskosten hängen von der angebundenen Konfiguration ab.

Zusatzplugins können eigene Designbereiche registrieren. Damit lassen sich auch externe Formulare oder branchenspezifische Seitenansichten in der gewohnten Designoberfläche anpassen, sofern das Plugin eine entsprechende Integration liefert.

VeloCore unterstützt responsive Frontend-Komponenten. Je nach Sektion stehen zusätzliche mobile Optionen zur Verfügung. Für neue kundenspezifische Sektionen sind Smartphone-, Tablet- und Desktop-Ansichten zu testen.

Beim Upload werden für unterstützte JPEG-/PNG-Bilder moderne WebP-Varianten und – soweit die Serverumgebung das Format unterstützt – AVIF-Varianten erzeugt. VeloCore verwendet passende Bildabmessungen und kann responsive Ausgaben mit srcset, sizes und geeigneten Fallbacks erstellen.

Im Administrationsbereich lässt sich die Ausgabequalität für JPEG, WebP und AVIF getrennt einstellen (jeweils 1–100). Die Einstellung wirkt auf neu erzeugte Bildvarianten; bereits erstellte Dateien werden dadurch nicht rückwirkend umgewandelt.

Alternativtexte, Bildbeschreibung, Copyright und Bildunterschrift können in die Darstellung einfließen. Welche Bildunterschrift tatsächlich sichtbar ist, hängt von der verwendeten Seiten-/Artikel-Sektion und den dort hinterlegten Daten ab.

Das Theme unterscheidet Beitragsbilder und im Artikel verwendete Bilder. Für die Darstellung können passende Größen und Formatvarianten gewählt werden. Doppelausgaben desselben Bildes sollten im jeweiligen Template geprüft werden.

Galerien, Slider, Slideshows, Video-Sektionen und videofähige Hintergründe sind vorhanden. Je nach Sektion können Mobile-Fokus, Loop und Overlay eingestellt werden. Große Medien sollten trotz optimierter Auslieferung angemessen vorbereitet werden.

Die Frontend-Ausgaben arbeiten mit passenden Bildattributen und können ressourcenschonend laden. Besonders das sichtbare Hauptbild sollte hinsichtlich Ladepriorität, Formatwahl und Abmessungen im fertigen Seitenkontext kontrolliert werden.

Eine AVIF-Erzeugung ist von der Serverunterstützung abhängig; exotische Eingabeformate sind nicht gleichzusetzen mit JPEG/PNG. Eine lückenlose Migration bereits vorhandener Altbestände erfordert gegebenenfalls einen separaten Regenerations- oder Rebuild-Lauf.

VeloCore verwaltet Seitentitel, Beschreibungen sowie relevante Open-Graph-/Sharing-Daten im Veröffentlichungsprozess. Bild, Titel und Anriss sollten pro Artikel sinnvoll gepflegt werden. Die tatsächliche Darstellung bei sozialen Netzwerken hängt auch von deren Caches und Crawlern ab.

Strukturierte Daten können für Website, Organisation/Person und redaktionelle Inhalte erstellt werden. Für Artikel und Seiten sind Schema-Typen wählbar; konfigurierte Unternehmens-/Personendaten und Öffnungszeiten können berücksichtigt werden.

Das Theme erzeugt und pflegt eigenständige Sitemap-Artefakte für Beiträge, Seiten, Kategorien und Autoren. Eine Sitemap-Indexdatei dient der gebündelten Auffindbarkeit. Bei Inhaltsänderungen werden passende Einträge aktualisiert.

Beiträge, Seiten und Archive erhalten strukturierte URLs. Kategorie- und Tag-Basen lassen sich abstimmen; Weiterleitungen, Canonicals und URL-Änderungen sind vor einem Relaunch gesondert zu prüfen.

Bei aktivem Sprachsystem kann die Ausgabe von hreflang-Verweisen und sprachbezogenen URLs verwaltet werden. Voraussetzung sind gepflegte Übersetzungen und eine konsistente URL-Konfiguration.

VeloCore enthält Funktionen zur Erzeugung maschinenlesbarer Orientierung für KI- und Suchdienste, etwa eine llms.txt-Ausgabe. Dies verbessert nicht garantiert Rankings oder KI-Zitationen; es stellt zusätzliche strukturierte Zugänge bereit.

Das Multilingual-Modul kann global aktiviert werden. Hauptsprache und zusätzliche aktive Sprachen sind in der Administration wählbar; die Sprachumschaltung kann an unterschiedlichen Positionen im Frontend erscheinen.

Für redaktionelle Inhalte bestehen Übersetzungsfunktionen einschließlich der Verarbeitung mehrerer Beiträge. Die Übersetzung kann über konfigurierte Anbieter erfolgen; die erstellten Texte bleiben vor Veröffentlichung fachlich und redaktionell zu prüfen.

Neben Artikeltexten können Navigation, Kategorietexte und weitere statische Oberflächenelemente sprachbezogen gepflegt bzw. übersetzt werden.

Die optionale Erkennung der Browsersprache beim Erstaufruf sowie hreflang-Verweise sind getrennt einstellbar. Die konkrete Zahl verfügbarer Sprachen folgt der eingebauten Sprachliste und der Aktivierung in der Installation.

Ein eigenes Kampagnensystem verwaltet Anzeigen mit Platzierung und Ausspielungsregeln. Anzeigen können in dafür vorgesehene Theme- und Pagebuilder-Positionen eingebunden werden. Eine separate Statistikansicht und Klickverfolgung sind vorhanden.

Kampagnen können mit redaktionellen Kontexten und zeitlichen Vorgaben kombiniert werden, soweit dies die jeweilige Anzeigenkonfiguration anbietet. Bei der Auslieferung sollten Einwilligung, externe Skripte und die reale Anzeige im Browser getestet werden.

Eine CMP-Funktion sowie ein Adblock-Detektor können separat aktiviert oder deaktiviert werden. Die rechtliche Bewertung der konkreten Konfiguration, Anbieter und Einwilligungstexte liegt beim Betreiber.

Für Artikel sind ein Audioplayer zur Wiedergabe bereits hinterlegter MP3-Dateien und ein PDF-Button für bereits hinterlegte PDF-Dateien vorgesehen. Anzeige, Beschriftung, Position und PDF-Öffnungsverhalten lassen sich einstellen. Das Aktivieren erzeugt nicht automatisch MP3- oder PDF-Dateien.

Ein Stripe-API-Schlüssel kann in der Theme-Konfiguration hinterlegt werden. Dies ist eine Integrationsmöglichkeit, aber für sich genommen noch kein vollständiges Abonnement-, Checkout- oder Buchungssystem. Solche Prozesse benötigen ein geeignetes Modul und eigene Prüfung.

VeloCore bereitet Beiträge, Seiten, Konfigurationen, Navigationsinformationen und Indizes als Dateien auf. Projekte können darauf abgestimmte Integrationen entwickeln, ohne für jede Auslieferung eine neue Datenbankabfrage durchzuführen. Pfade und Dateizugriffsrechte sind installationsabhängig; nicht jede interne Datei ist als öffentliche API freizugeben.

Das Backend bleibt WordPress und damit ein nutzbarer Integrationspunkt für Redaktion, Benutzer, Medien und vorhandene Import-Workflows. Plugins, die ausschließlich Frontend-Hooks oder dynamische Ausgabe in wp_head()/wp_footer() benötigen, funktionieren im entkoppelten Auslieferungsweg nicht ohne Anpassung.

Eigene Plugins können Pagebuilder-Sektionen mit Eingabefeldern, Ausgabe, Styles und eigener Speicherung beisteuern. Dies erlaubt fachspezifische Features, etwa Formular-, Branchenbuch- oder Hotelmodule, ohne den zentralen Theme-Kern zu duplizieren.

Externe Module können ihre Bereiche im Design-Manager anbieten. Redaktion und Agentur können dadurch auch Modul-Styles zentral bearbeiten. Die Integration muss das jeweilige Plugin explizit vorsehen.

VeloCore unterstützt deklarierte Erweiterungspunkte für zusätzliche Ausgabebausteine. So können unterschiedliche Plugins projektbezogen eingebunden und getrennt verwaltet werden. Welche Slots verfügbar sind, hängt vom eingesetzten Theme- und Modulstand ab.

Zu den erkennbaren Integrationspunkten zählen Stripe, Übersetzungsdienste und eigene REST-Clients. Eine native, fertig konfigurierte Anbindung an ein bestimmtes Verlagssystem, DAM, ERP, CRM oder eine Abo-Plattform wird hier nicht ohne separates Modul zugesichert. Individuelle Adapter lassen sich projektbezogen entwickeln.

Für produktive Fremdsysteme sollten Autorisierung, Rate Limits, Cacheverhalten, Feldverfügbarkeit, Fehlercodes, datenschutzrechtliche Anforderungen und die Versionierung der verwendeten Endpunkte verbindlich dokumentiert und getestet werden.

Ein gültiger Fast-Path-Treffer kommt ohne die Ausführung des WordPress-/PHP-Frontends aus. Dadurch wird die für Besucher ausgeführte Angriffsoberfläche reduziert. Das ersetzt jedoch weder Sicherheitsupdates noch die Absicherung von WordPress-Admin, Server und integrierten Diensten.

Das Theme enthält Login-Begrenzungs- und Vorschau-Schutzmaßnahmen. Entwürfe und nicht öffentliche Inhalte dürfen nicht über frei erreichbare Artefakte ausgeliefert werden; dies ist bei jedem individuellen Erweiterungsmodul mit zu prüfen.

Kontakt- und Kommentarformulare sind mit Challenge-Endpunkten gekoppelt. Formulare, die Sitzungen, POST-Verarbeitung oder Drittskripte benötigen, müssen für den Fast-Path gesondert behandelt werden.

CMP, Tracking, Werbung, Sprachdienste, eingebettete Medien und Zahlungsanbieter sind pro Installation zu konfigurieren. VeloCore ist kein Ersatz für eine individuelle Datenschutzprüfung oder rechtliche Freigabe.

Die Redaktion nutzt die WordPress-Benutzer- und Berechtigungsbasis. Administrative Import-, Design- und Rebuild-Funktionen erfordern entsprechende Rechte. Für größere Verlage empfiehlt sich eine Trennung zwischen Redaktion, Layoutpflege und technischem Betrieb.

Redaktionelle Berechnung wird so weit wie möglich in den Veröffentlichungs- und Build-Zeitpunkt verschoben. Besucher erhalten vorbereitete Daten oder direktes HTML. Damit entfallen viele dynamische Arbeiten pro Seitenaufruf.

Auf gleichem Server kann eine statisch ausgelieferte Seite wesentlich weniger CPU-Zeit benötigen als eine vollständig dynamische WordPress-Seite. Die tatsächliche Anzahl gleichzeitiger Nutzer, RPS und Antwortzeit hängt von Hosting, Netzwerk, Cache, HTML-Größe und Erweiterungen ab; feste x-fache Vorteile sind keine allgemeine Garantie.

Erkannte Abhängigkeiten erlauben bei Inhaltsänderungen gezielte Neubauten. Bei globalen Änderungen stehen kontrollierte vollständige Rebuilds zur Verfügung.

Vorbereitete Styles, responsive Bildvarianten und moderne Formate können Übertragungsvolumen und Rendering-Arbeit reduzieren. Für Core Web Vitals bleiben Layout, Werbeskripte, externe Dienste und Netzwerkbedingungen relevant.

Statische HTML-/Asset-Auslieferung lässt sich mit üblichen Webserver- und CDN-Strategien kombinieren. Cache-Invalidierung, Proxy-Verhalten und personalisierte Inhalte sind projektspezifisch abzustimmen.

WordPress als Verwaltungsbasis, ein unterstütztes PHP-/Webserver-Setup, Schreibrechte für VeloCore-Artefakte sowie die benötigten Serverfunktionen für Medien und Rewrite-Regeln. Der hier dokumentierte Fast-Path nutzt Apache und die passende Rewrite-Konfiguration. Bei nginx, Proxies und anderen Umgebungen ist eine eigene Integrations- und Liveprüfung nötig.

VeloCore Theme aktivieren, Grundeinstellungen für Branding, URLs, Menüs und Footer vornehmen, Design konfigurieren, gewünschte Seiten/Artikel veröffentlichen und die vorbereiteten Daten über die vorgesehenen Rebuild-Funktionen erstellen.

Runtime Engine als eigenes Plugin einrichten. Im Adminbereich Apache-Installationszustand kontrollieren, Fast-Path aktivieren, vollständigen Aufbau durchführen und mehrere repräsentative URLs (Startseite, Beitrag, Seite, Archiv) live mit Response-Headern prüfen.

Die Suite stellt Verwaltungs- und Statusansichten für relevante Artefakte und Konfigurationen bereit. Die Runtime führt eigene Dokumententscheidungen und Rebuild-Statistiken. Bei Fehlern zuerst Status, Rechte, fehlende Artefakte und Rewrite-Reihenfolge prüfen.

Für globale Designs, Menüs, Taxonomie- und Strukturänderungen einen kontrollierten Rebuild einplanen. Danach stichprobenartig URL, Canonical, Metadaten, Bilder, dynamische Formulare und Fast-Path-Header kontrollieren.

Regelmäßig WordPress-Datenbank, Uploads, Theme-/Plugin-Dateien, individuelle Konfigurationen und Build-relevante Artefakte sichern. Ein vollständiger Rebuild kann die Ausgabeartefakte erneut erzeugen, ersetzt aber kein Backup der redaktionellen Quelldaten oder kundenspezifischer Module.

Bei vorgeschalteten Caches und Proxies sind Status-Header, Rewrites, Cache-Keys und Aktualisierungsregeln auf dem öffentlichen Weg zu validieren. Ein lokal gültiger Apache-Regelblock allein beweist noch keine Fast-Path-Auslieferung bis zum Endnutzer.

Kategorie in WordPress anlegen, gewünschte URL-Basis prüfen, Archivdarstellung konfigurieren, Rubrik im Menü ergänzen und passende Newssektionen auf Start-/Themenseiten setzen. Veröffentlichung und betroffene Ausgaben kontrollieren.

Pagebuilder-Seite erstellen, Sektionen konfigurieren, Bilder und Buttons hinterlegen, bei Bedarf Sichtbarkeit zeitlich steuern. Eine fertige Seite kann als JSON-Vorlage auf weitere Projekte übertragen und dort angepasst werden.

Globalfarben, Fonts und betroffene Design-Manager-Bereiche bearbeiten. Nach Freigabe dynamische Styles und – bei aktivem Fast-Path – die betroffenen HTML-Seiten aktualisieren. Im Anschluss repräsentative Seitentypen testen.

Redaktionelle Massenimporte im Backend ausführen, VeloCore-Artefaktstatus überwachen und bei Bedarf einen Gesamtabgleich/Rebuild starten. Such-/Archivindizes, Pagination, Sitemaps und Fast-Path-Stände stichprobenartig gegen WordPress prüfen.

Anforderungen in Inhalte, Adminoberfläche, Frontend-Ausgabe und Datenzugriffe aufteilen. Für neue Darstellungen Pagebuilder- und Design-Manager-Erweiterungspunkte nutzen; dynamische Transaktionen getrennt behandeln und ihre Fast-Path-Tauglichkeit ausdrücklich bewerten.

Zuerst Publikationsstatus und passende Artefakte prüfen. Danach Theme-Rebuild, Fast-Path-Dokumententscheidung und gegebenenfalls CDN-/Browsercache kontrollieren. Nie pauschal davon ausgehen, dass jede Änderung ausschließlich über WordPress-Template-Caches läuft.