WordPress speichert nicht mehr vollständig

Du speicherst einen Beitrag, eine Seite oder Einstellungen in WordPress - und ein Teil deiner Eingaben ist danach einfach weg. Häkchen sind zurückgesetzt, Custom Fields leer, der Footer-Text verschwunden. Die Datei selbst zeigt keinen Fehler, das Backend meldet "gespeichert". Trotzdem fehlen Daten.

Dieses Problem ist seit Jahren ein Klassiker und hat 2026 drei dominierende Ursachen: das PHP-Limit max_input_vars, eine zu aggressive ModSecurity-Regel beim Hoster und in selteneren Fällen die alte Suhosin-Extension. Wer schnell weiß, wo er nachschauen muss, ist in 10 Minuten durch.

So erkennst du dieses Problem zuverlässig Speichern funktioniert "halb": ein Teil bleibt erhalten, ein Teil ist weg. Häufig betroffen sind Häkchen (z.B. Kommentare zulassen, ping_status), Custom Fields, ACF-Felder, lange Menüs, Page-Builder-Inhalte und Footer-/Header-Bereiche aus Theme-Optionen. Wenn das Backend sogar mit "The link you followed may be broken" antwortet, ist es fast immer ModSecurity.

Schnelldiagnose: was ist es?

Symptom	Wahrscheinliche Ursache	Wo nachschauen
Lange Beiträge oder Custom Fields werden nur teilweise gespeichert	`max_input_vars` zu niedrig (PHP-Standard: 1000)	php.ini, .htaccess, Hoster-Panel
"The link you followed may be broken" beim Speichern	ModSecurity blockt den Request	Hoster-Kundenbereich (Sicherheit)
500er-Fehler oder Timeout beim Speichern	`post_max_size` oder `memory_limit` zu klein	php.ini, Hoster-Panel
Fehler im Error-Log: "configured POST variable limit exceeded"	Suhosin (alter Server, eigener VServer)	suhosin.ini
Speichern komplett ohne Fehler, aber Daten weg	Plugin-Konflikt oder Theme-Filter	Plugin-Test, siehe WordPress reparieren

Schritt 1: Debug-Modus an und Error-Log öffnen

Bevor du irgendwas änderst, lass WordPress dir sagen, was kaputt ist. Öffne die wp-config.php im Hauptverzeichnis und ersetz die Debug-Zeile:

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
@ini_set('display_errors', 0);

WordPress schreibt jetzt jeden Fehler in wp-content/debug.log. Speicher dann erneut den Beitrag, der das Problem auslöst. Schau direkt danach in zwei Dateien:

WordPress-Log: wp-content/debug.log - hier landen PHP-Warnings, fatale Fehler und WordPress-interne Meldungen.
Server-Error-Log: bei All-Inkl im KAS unter "Statistik → Fehlerprotokoll", bei IONOS unter "Hosting → Logs". Hier landen Meldungen vom Apache, ModSecurity und PHP-Crashs.

Wenn du dort eine Zeile mit configured POST variable limit exceeded findest, ist es Suhosin (siehe Schritt 4). Wenn du eine ModSecurity-ID wie id 942100 oder id 920273 siehst, geh direkt zu Schritt 3. Findest du Zeilen wie PHP Warning: Input variables exceeded 1000, ist es max_input_vars (Schritt 2).

Schritt 2: max_input_vars erhöhen (häufigster Fall)

PHP begrenzt seit Version 5.3 standardmäßig die Anzahl der Variablen, die in einem einzigen Request übertragen werden dürfen. Der Default ist 1000. Klingt viel - reicht aber nicht für lange Beiträge mit vielen Custom Fields, große Menüs (50+ Einträge), ACF mit Repeater Fields, WooCommerce-Bestellungen mit Optionen, oder ein Theme mit umfangreichem Customizer.

So erhöhst du den Wert, je nach Zugriff auf dein Hosting:

Variante A: über das Hoster-Kundenpanel

Der einfachste Weg. Bei den meisten Shared-Hostern findest du im Kundenbereich eine Übersicht für PHP-Einstellungen:

All-Inkl (KAS): Domain → PHP-Version & Einstellungen → max_input_vars auf 3000 setzen.
IONOS: Hosting → PHP-Einstellungen pro Domain.
Strato: Paketverwaltung → PHP-Konfiguration.
Hetzner Konsoleh: WebHosting → PHP-Konfiguration → max_input_vars.

Setz den Wert auf 3000. Für sehr große WooCommerce-Shops oder komplexe ACF-Konstruktionen sind auch 5000 problemlos.

Variante B: per .htaccess

Wenn dein Hoster es zulässt (viele tun das), kannst du das Limit über die .htaccess im WordPress-Hauptverzeichnis setzen. Trag diese Zeilen oberhalb des WordPress-Blocks ein:

php_value max_input_vars 3000
php_value post_max_size 64M
php_value memory_limit 256M

Falls das einen 500er-Fehler verursacht, hat dein Hoster php_value per .htaccess deaktiviert (üblich bei FastCGI/PHP-FPM-Setups). In dem Fall geht es nur über das Kundenpanel oder eine eigene php.ini im Hauptverzeichnis.

Variante C: per php.ini im Hauptverzeichnis

Bei einigen Hostern kannst du eine eigene php.ini oder .user.ini im WordPress-Hauptverzeichnis ablegen, in der du deine PHP-Werte überschreibst:

max_input_vars = 3000
post_max_size = 64M
memory_limit = 256M

Nach dem Anlegen dauert es bis zu 5 Minuten, bis PHP die neue Konfiguration einliest. Du kannst die geltenden Werte über eine eigene Test-Datei prüfen: Erstell eine Datei phpinfo.php mit dem Inhalt <?php phpinfo(); ?> und ruf sie über den Browser auf. Such dort nach max_input_vars. Wichtig: lösch die Datei nach dem Test wieder - sie verrät Angreifern Details zu deiner PHP-Konfiguration.

Schritt 3: ModSecurity beim Hoster prüfen

ModSecurity ist eine Sicherheits-Firewall, die viele Shared-Hoster vor PHP schalten. Sie blockt verdächtige Requests, bevor sie WordPress überhaupt erreichen. Bei zu strikten Regeln wird WordPress fälschlich als Angreifer erkannt - meistens beim Speichern von HTML im Editor (z.B. einer Tabelle oder eines iframe-Embeds).

Typische Symptome bei ModSecurity-Blockade:

"The link you followed may be broken, or the page may have been removed" - dieser Text kommt direkt von WordPress, wenn der POST-Request unterwegs gestoppt wurde.
403 Forbidden direkt im Editor beim Klick auf "Aktualisieren".
Im Server-Error-Log: Zeilen mit ModSecurity: Access denied und einer Rule-ID (oft 942100, 920273, 949110).

So gehst du vor:

Such im Hoster-Kundenbereich nach "ModSecurity", "WebApplicationFirewall" oder "Sicherheit". Bei vielen Anbietern kannst du ModSecurity pro Domain ein- und ausschalten.
Schalt es kurz aus, speicher den Beitrag und schalt es sofort wieder ein. Wenn das Speichern jetzt klappt, weißt du, dass ModSecurity der Übeltäter ist.
Schreib deinem Hoster-Support eine kurze Mail mit der Rule-ID aus dem Log und der Bitte, diese Regel für deine Domain zu lockern oder zu deaktivieren. Bei All-Inkl und IONOS reagiert der Support meist innerhalb weniger Stunden.

Warum nicht einfach ModSecurity ganz aus lassen? ModSecurity blockt viele Angriffsversuche (SQL Injection, XSS, Brute Force) bevor sie WordPress erreichen. Komplett abschalten erhöht dein Sicherheitsrisiko spürbar. Besser: einzelne Regeln deaktivieren, die zu nervös sind.

Schritt 4: Suhosin (Eigenserver, alte Setups)

Die Suhosin-Extension war über Jahre die Standard-Sicherheitserweiterung für PHP auf Debian- und Ubuntu-Servern. Sie ist seit PHP 7 nicht mehr aktiv weiterentwickelt und in modernen Shared-Hosting-Umgebungen praktisch verschwunden. Trotzdem läuft sie noch auf einigen alten VServern und älteren Managed-Hosting-Umgebungen.

Hinweis im Error-Log:

ALERT - configured POST variable limit exceeded - dropped variable 'meta[23252][key]'

Wenn du Root-Zugriff auf den Server hast, öffne die Suhosin-Konfiguration:

sudo nano /etc/php/8.2/apache2/conf.d/suhosin.ini

Setz die beiden Werte auf 500 oder höher (achte darauf, dass das führende Semikolon entfernt ist):

suhosin.post.max_vars = 500
suhosin.request.max_vars = 500

Apache neu starten, fertig:

sudo systemctl restart apache2

Bei Nginx mit PHP-FPM heißt der Dienst entsprechend php8.2-fpm. Wenn du keinen Server-Zugang hast und der Hoster auf Suhosin besteht, hilft nur ein Support-Ticket oder ein Wechsel des Anbieters - moderne Hoster nutzen heute ModSecurity statt Suhosin.

Schritt 5: post_max_size und memory_limit

Wenn dein Beitrag sehr lang ist (z.B. ein 30.000-Wörter-Artikel mit vielen eingebetteten Bildern) oder du WooCommerce-Bestellungen mit dutzenden Positionen speicherst, kann auch die maximale Größe des POST-Requests zum Problem werden. Setz die beiden Werte mit hoch:

post_max_size = 64M
memory_limit = 256M
upload_max_filesize = 64M

Wichtig: post_max_size muss größer sein als upload_max_filesize, sonst funktionieren Datei-Uploads nicht mehr richtig.

Was, wenn nichts hilft?

Wenn du alle drei Limits hochgesetzt hast, ModSecurity geprüft hast und es immer noch nicht klappt, liegt das Problem wahrscheinlich nicht an Limits, sondern an einem Plugin oder Theme, das beim Speichern Daten manipuliert oder löscht. Dafür gibt es einen eigenen Diagnose-Pfad: deaktivier alle Plugins, setz das Theme auf einen Standard zurück und schau, ob es dann funktioniert. Detaillierte Anleitung dazu im Hub WordPress reparieren.

Bekommst du das Problem nicht alleine in den Griff?

Wenn die Seite live für Kunden gebraucht wird, du keinen Zugriff auf die PHP-Konfiguration hast oder du dir bei den Eingriffen unsicher bist: melde dich kurz, ich schau drauf.

WordPress-Hilfe anfragen bei weihmann.de →

Häufige Fragen

Wie hoch sollte ich max_input_vars setzen?

Für normale Blogs reichen 3000. Für WooCommerce-Shops oder Seiten mit komplexem ACF-Setup sind 5000 angemessen. Werte über 10000 deuten meist auf ein Plugin-Problem hin, nicht auf einen ehrlichen Bedarf.

Verschlechtert ein hoher max_input_vars-Wert die Sicherheit?

Marginal. Das Limit ist eher eine Schutzmaßnahme gegen DoS-Angriffe als gegen klassische Exploits. Eine Erhöhung auf 3000 oder 5000 ist unkritisch, solange du grundlegende Sicherheitsmaßnahmen (Updates, gute Passwörter, gute Plugins) einhältst.

Wo finde ich die ModSecurity-Logs?

In den Error-Logs deines Hosters. Die Zeile beginnt typischerweise mit [error] [client IP] und enthält ModSecurity: Access denied sowie eine [id "..."]-Angabe, die die ausgelöste Regel identifiziert.

Kann ich erkennen, ob mein Hoster ModSecurity nutzt?

Ja: in den Response-Headern erscheint oft X-Mod-Security: yes oder ein eigener Status-Header. Schau im Browser unter Entwicklertools → Netzwerk-Tab nach den Response-Headern. Alternativ: schau ins Hoster-Panel nach "Sicherheit" oder "Web Application Firewall".

Wie teste ich, ob meine PHP-Werte wirklich aktiv sind?

Leg im WordPress-Hauptverzeichnis eine Datei phpinfo.php mit <?php phpinfo(); ?> an, ruf sie im Browser auf und such mit Strg+F nach dem Wert. Danach sofort wieder löschen, sonst sind deine Server-Details öffentlich einsehbar.

Mein Hoster antwortet nicht und ich komme nicht selbst an die PHP-Konfiguration. Was tun?

Frag explizit nach dem Wert max_input_vars und nach ModSecurity. Wenn der Support unkooperativ ist, ist das oft ein Zeichen, den Anbieter zu wechseln - bei All-Inkl, Raidboxes, Hetzner und IONOS hast du PHP-Werte selbst in der Hand.

WordPress speichert nicht mehr vollständig - Lösung