WordPress nach der Installation: Checkliste mit 50 Punkten für 2026

Die “berühmte 5-Minuten-Installation” ist ein Werbeslogan, kein professioneller Standard. Eine WordPress-Standardinstallation ist “gesprächig”, nicht optimiert und oft unsicher.

Als Entwickler “installieren” wir WordPress nicht einfach. Wir bereiten es für den Betrieb in einer bestimmten Umgebung vor. Dieser Leitfaden behandelt die wichtigsten Konfigurationskonstanten und Hardening-Techniken, die 2026 zur Grundausstattung jedes Kundenprojekts gehören sollten.

#wp-config.php nach der WordPress-Installation konfigurieren

Das ist das Gehirn Ihrer Installation. Lassen Sie es nicht länger auf den Standardeinstellungen.

#WP_ENVIRONMENT_TYPE in wp-config.php setzen

Seit WordPress 5.5 ist WP_ENVIRONMENT_TYPE Standard. Nutzen Sie die Konstante, damit Entwicklungsfehler nicht in die Produktion durchsickern.

// In wp-config.php
define( 'WP_ENVIRONMENT_TYPE', 'production' ); // 'local', 'development', 'staging', 'production'

Dann in Ihrem Code:

if ( wp_get_environment_type() === 'production' ) {
    // Cache aktivieren, Fehler deaktivieren
}

#Dateieditor deaktivieren und SSL in wp-config.php erzwingen

Verhindern Sie, dass Kunden (oder Angreifer) die Website über das Admin-Panel beschädigen.

// Dateieditor deaktivieren (Theme-/Plugin-Editor)
define( 'DISALLOW_FILE_EDIT', true );

// Installation/Aktualisierung von Plugins sperren (gut für unveränderliche Deployments)
define( 'DISALLOW_FILE_MODS', true );

// SSL im Admin erzwingen
define( 'FORCE_SSL_ADMIN', true );

#Beitragsrevisionen in WordPress begrenzen

Der Datenbank-Killer. Brauchen Sie wirklich 100 Versionen der Seite “Über uns”?

define( 'WP_POST_REVISIONS', 10 ); // Die letzten 10 behalten
// ODER
define( 'WP_POST_REVISIONS', false ); // Vollständig deaktivieren (nicht empfohlen)

#WP_DEBUG_LOG aktivieren, ohne Fehler anzuzeigen

Zeigen Sie Fehler nie im Frontend an. Protokollieren Sie sie.

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', '/tmp/wp-errors.log' ); // Log außerhalb des öffentlichen Verzeichnisses ablegen!
define( 'WP_DEBUG_DISPLAY', false );

// SQL-Abfragen zum Performance-Debugging protokollieren (in Produktion deaktivieren!)
define( 'SAVEQUERIES', false );

#Emoji und XML-RPC in WordPress deaktivieren

WordPress bringt Funktionen mit, die 90% der Unternehmenswebsites nicht brauchen: Emoji, oEmbeds und XML-RPC.

Installieren Sie kein Plugin, um sie abzuschalten. Legen Sie ein Must-Use-Plugin an (wp-content/mu-plugins/lean-core.php).

<?php
/* Plugin Name: Lean Core */

// 1. Emoji deaktivieren (spart einen HTTP-Request)
remove_action( 'wp_head', 'print_emoji_detection_script', 7 );
remove_action( 'wp_print_styles', 'print_emoji_styles' );

// 2. XML-RPC deaktivieren (Sicherheit)
add_filter( 'xmlrpc_enabled', '__return_false' );

// 3. WP-Version entfernen (Security by Obscurity)
remove_action( 'wp_head', 'wp_generator' );

// 4. RSS-Feeds deaktivieren (wenn Sie eine reine Firmenwebsite bauen)
// function wppoland_disable_feed() {
//    wp_die( 'Kein Feed vorhanden, besuchen Sie unsere Startseite!' );
// }
// add_action('do_feed', 'wppoland_disable_feed', 1);

Der Filter xmlrpc_enabled aus Punkt 2 schaltet entgegen seinem Namen nur XML-RPC-Methoden ab, die eine Authentifizierung verlangen, etwa das Veröffentlichen. Pingbacks und andere Methoden ohne Authentifizierung antworten weiterhin unter xmlrpc.php. Die ganze Datei sperrt man auf dem Webserver, und nur dann, wenn nichts sie nutzt: Jetpack zum Beispiel verbindet sich über XML-RPC.

#Salt-Schlüssel in wp-config.php ändern

Sie kennen die Authentifizierungsschlüssel in wp-config.php.

define('AUTH_KEY',         'geben Sie hier Ihre eindeutige Phrase ein');
// ...

Fakt: Eine Änderung meldet sofort alle Benutzer ab. Das ist die “Notfalloption”, wenn die Website gehackt wurde. Profi-Tipp: Automatisieren Sie die Rotation mit einem CLI-Skript oder Vault, wenn Sie Enterprise-Websites betreuen.

#Was Sie vor dem Livegang in wp-config.php setzen sollten

Vor dem Launch:

1. WP_ENVIRONMENT_TYPE auf production setzen.
2. DISALLOW_FILE_EDIT auf true setzen.
3. WP_POST_REVISIONS begrenzen.
4. WP_DEBUG_LOG in einen privaten Ordner verschieben.
5. Emoji/XML-RPC per Code deaktivieren.

Eine gut konfigurierte WordPress-Instanz ist leise, sicher und schnell.

#Welche Permalinks Sie in WordPress einstellen sollten

#Die optimale Permalink-Struktur

Einstellungen > Permalinks > Beitragsname

Warum:

• Kürzere, lesbarere URLs
• Besser für SEO (Keywords in der URL)
• Leichter zu merken und zu teilen

Eine frische Installation hat oft schon sprechende Permalinks. Unterstützt der Server URL-Rewriting, setzt der Installer /%year%/%monthnum%/%day%/%postname%/ (die Core-Funktion wp_install_maybe_enable_pretty_permalinks()). Stellen Sie auf Beitragsname um, bevor der erste Beitrag erscheint: Eine Änderung der Struktur auf einer laufenden Website ändert die URL jedes Beitrags, und die alten Adressen brauchen dann Weiterleitungen.

#Struktur von Kategorien und Schlagwörtern

1. Grundlegende Kategorien anlegen (3-7 Hauptkategorien)
2. Hierarchie festlegen (über- und untergeordnete Kategorien)
3. Standardkategorie setzen (nicht “Allgemein”)
4. Schlagwort-Strategie planen (optional, 5-10 Schlagwörter pro Beitrag)

#WordPress-Medieneinstellungen und Bildgrößen

#Bildgrößen

Einstellungen > Medien

Empfohlene Einstellungen:

• Vorschaubild: 150x150px (“Vorschaubild auf exakte Größe zuschneiden” aktivieren)
• Mittelgroß: 300x300px
• Groß: 1024x1024px
• Volle Größe: immer verfügbar

#Automatische Bildoptimierung

<?php
/* Plugin Name: Image Sizes */

add_action( 'init', function () {
    remove_image_size( '1536x1536' ); // WordPress 5.3+
    remove_image_size( '2048x2048' ); // WordPress 5.3+
} );

Zwei Zeilen, die in verbreiteten Kopien dieses Snippets stehen, fehlen hier bewusst. wp_lazy_loading_enabled liefert standardmäßig bereits true (natives loading="lazy" seit WordPress 5.5), und der Filter wp_image_editors legt nur die Reihenfolge fest, in der WordPress Imagick und GD versucht, und das ist ohnehin die Standardreihenfolge. Keiner von beiden optimiert beim Hochladen etwas. Bilder, die breiter oder höher als 2560 px sind, verkleinert WordPress beim Hochladen bereits über den Filter big_image_size_threshold.

#WebP-Uploads in WordPress aktivieren

add_filter( 'image_editor_output_format', function ( $formats ) {
    $formats['image/jpeg'] = 'image/webp';
    $formats['image/png']  = 'image/webp';
    return $formats;
} );

Das Snippet nutzt nicht wp_upload_image_mime_transforms, einen Filter, den es im aktuellen WordPress-Core nicht gibt. image_editor_output_format existiert seit WordPress 5.8 und ordnet einem Quelltyp den Typ zu, in dem WordPress die erzeugten Größen speichert; seit 6.7 wandelt der Standardwert bereits HEIC und HEIF in JPEG um, und das Snippet behält diese Einträge. Imagick oder GD auf dem Server muss WebP unterstützen. Werkzeuge > Website-Zustand > Bericht > Medienverarbeitung zeigt, was unterstützt wird.

#WordPress nach der Installation absichern

#Standard-Tabellenpräfix ändern

Bei der Installation: Geben Sie statt wp_ ein eigenes Präfix ein (zum Beispiel x7k9_, mysite_, proj23_)

Nach der Installation (fortgeschritten):

// wp-config.php
$table_prefix = 'x7k9_';

RENAME TABLE wp_posts TO x7k9_posts;
RENAME TABLE wp_options TO x7k9_options;
-- ... für alle Tabellen wiederholen

UPDATE x7k9_options SET option_name = 'x7k9_user_roles' WHERE option_name = 'wp_user_roles';
UPDATE x7k9_usermeta SET meta_key = CONCAT('x7k9_', SUBSTRING(meta_key, 4)) WHERE meta_key LIKE 'wp\_%';

WordPress kennt keine Konstante DB_PREFIX: Das Präfix steht in der Variable $table_prefix. Wer nur die Tabellen umbenennt, sperrt die Administratoren aus, weil Rollen und Berechtigungen unter Schlüsseln mit Präfix in options (wp_user_roles) und usermeta (wp_capabilities, wp_user_level) liegen. Genau das korrigieren die beiden UPDATE-Anweisungen. Der Leitfaden Hardening WordPress behandelt ein eigenes Präfix als Verschleierung: Es kann einige automatisierte SQL-Injection-Angriffe blockieren, die wp_ voraussetzen, ersetzt aber nicht die Korrektur von angreifbarem Code.

#Die Datei wp-config.php schützen

# .htaccess (Hauptverzeichnis, ganz oben in der Datei)
<Files "wp-config.php">
Require all denied
</Files>

Order allow,deny ist Syntax von Apache 2.2 und funktioniert unter Apache 2.4 nur über das Kompatibilitätsmodul. Der Leitfaden Hardening WordPress gibt die obige Form Require all denied an und setzt sie ganz oben in die .htaccess im Hauptverzeichnis. Nginx ignoriert .htaccess-Dateien, dort gehört dieselbe Regel in den server-Block.

#Zugriff auf Verzeichnisse sperren

# wp-content/uploads/.htaccess
Options -Indexes

# .htaccess (Hauptverzeichnis, außerhalb von # BEGIN WordPress und # END WordPress)
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^wp-admin/includes/ - [F,L]
RewriteRule !^wp-includes/ - [S=3]
RewriteRule ^wp-includes/[^/]+\.php$ - [F,L]
RewriteRule ^wp-includes/js/tinymce/langs/.+\.php - [F,L]
RewriteRule ^wp-includes/theme-compat/ - [F,L]
</IfModule>

WordPress überschreibt beim Speichern der Permalinks alles zwischen den Markierungen # BEGIN WordPress und # END WordPress, deshalb steht dieser Block außerhalb davon, in der .htaccess im Hauptverzeichnis und nicht in wp-includes/: Die Pfade in den Regeln gelten relativ zum Hauptverzeichnis der Website. In Multisite hindert die Zeile ^wp-includes/[^/]+\.php$ ms-files.php daran, Bilder auszuliefern, und der Leitfaden Hardening WordPress rät, diese Zeile dort wegzulassen, auf Kosten eines Teils des Schutzes.

#Anmeldeversuche begrenzen

<?php
/* Plugin Name: Login Security */

function wppoland_login_key() {
    return 'login_attempts_' . md5( $_SERVER['REMOTE_ADDR'] );
}

add_filter( 'authenticate', function ( $user ) {
    if ( (int) get_transient( wppoland_login_key() ) >= 5 ) {
        return new WP_Error( 'too_many_attempts', 'Zu viele Anmeldeversuche. Bitte in einer Stunde erneut versuchen.' );
    }
    return $user;
}, 30 );

add_action( 'wp_login_failed', function () {
    $key = wppoland_login_key();
    set_transient( $key, (int) get_transient( $key ) + 1, HOUR_IN_SECONDS );
} );

remove_action( 'wp_head', 'wp_generator' );
add_filter( 'the_generator', '__return_empty_string' );

Fehlversuche in wp_login_failed zu zählen und dort wp_die() aufzurufen, funktioniert nicht. Dieser Hook läuft nach der Passwortprüfung, ein korrektes Passwort meldete also auch nach fünf Fehlversuchen an. Der Filter authenticate mit Priorität 30 läuft, nachdem der Core Benutzername und Passwort geprüft hat, und ein dort zurückgegebener WP_Error stoppt die Anmeldung. Hinter einem CDN oder Reverse Proxy enthält REMOTE_ADDR die Adresse des Proxys, und alle Besucher würden sich einen Zähler teilen: In solchen Setups begrenzen Sie Anmeldungen am Proxy oder mit fail2ban auf dem Server.

#Zwei-Faktor-Authentifizierung (2FA)

Der WordPress-Core hat keinen zweiten Faktor. Das Plugin Two Factor, auf WordPress.org unter dem Konto WordPress.org veröffentlicht, ergänzt Authenticator-Apps (TOTP), Codes per E-Mail und Backup-Codes, und jeder Benutzer schaltet es im eigenen Profil ein. Der Leitfaden Hardening WordPress empfiehlt die Zwei-Schritt-Authentifizierung als zusätzliche Schicht zum Passwort. Das Snippet unten leistet weniger: Es lehnt beim Speichern eines Profils Passwörter unter 12 Zeichen ab.

// Starke Passwörter erzwingen
add_action('user_profile_update_errors', function($errors) {
    $password = $_POST['pass1'];
    if (!empty($password) && strlen($password) < 12) {
        $errors->add('password_error', 'Das Passwort muss mindestens 12 Zeichen lang sein.');
    }
});

#WordPress nach der Installation beschleunigen

#Grundlegende Datenbankoptimierung

// In wp-config.php
// Beitragsrevisionen begrenzen
define('WP_POST_REVISIONS', 10);

// Papierkorb automatisch nach 7 Tagen leeren
define('EMPTY_TRASH_DAYS', 7);

// Dateieditor deaktivieren (Sicherheit + Performance)
define('DISALLOW_FILE_EDIT', true);

#Datenbank bereinigen

wp transient delete --expired
wp post list --post_type=revision --format=count
wp db optimize

Das entfernte MU-Plugin löschte Transients, indem es option_value mit der aktuellen Zeit verglich, die Ablaufzeit steht aber in eigenen _transient_timeout_-Zeilen, also löschte es die falschen Zeilen. Der Core erledigt das bereits: wp-admin/admin.php plant ein tägliches Ereignis delete_expired_transients (übersprungen, wenn ein persistenter Objekt-Cache die Transients hält), und ein tägliches Ereignis wp_scheduled_auto_draft_delete entfernt automatische Entwürfe, die älter als sieben Tage sind. Mit gesetztem WP_POST_REVISIONS brauchen auch Revisionen keinen Lösch-Cron. Die WP-CLI-Befehle oben führen Sie von Hand aus, wenn eine Datenbank aufgebläht wirkt.

#Heartbeat API optimieren

add_filter( 'heartbeat_settings', function ( $settings ) {
    $settings['interval'] = 120; // Standard: 60
    return $settings;
} );

add_action( 'init', function () {
    if ( ! is_admin() ) {
        wp_deregister_script( 'heartbeat' );
    }
}, 1 );

Das Standardintervall von Heartbeat beträgt 60 Sekunden (mainInterval in heartbeat.js), nicht 15, der frühere Wert 60 änderte also nichts. Heartbeat verlangsamt sich außerdem selbst auf 120 Sekunden, wenn der Browser-Tab verborgen ist. Im Editor transportiert es die Beitragssperren, ein längeres Intervall verzögert also den Hinweis, dass jemand anderes denselben Beitrag bearbeitet.

#RSD-, Shortlink- und REST-API-Links aus wp_head entfernen

// Im MU-Plugin: wp-content/mu-plugins/disable-bloat.php
<?php
/* Plugin Name: Disable Bloat */

// Emoji deaktivieren
remove_action('wp_head', 'print_emoji_detection_script', 7);
remove_action('wp_print_styles', 'print_emoji_styles');

// XML-RPC deaktivieren
add_filter('xmlrpc_enabled', '__return_false');

// RSD-Link deaktivieren
remove_action('wp_head', 'rsd_link');

// Windows-Live-Writer-Link deaktivieren
remove_action('wp_head', 'wlwmanifest_link');

// Shortlink deaktivieren
remove_action('wp_head', 'wp_shortlink_wp_head');

// REST-API-Link deaktivieren (falls nicht genutzt)
remove_action('wp_head', 'rest_output_link_wp_head');

#Grundlegende SEO-Einstellungen in WordPress

#Seitentitel, Untertitel und Sichtbarkeit für Suchmaschinen

Einstellungen > Allgemein:
- Titel der Website: [Ihre Marke]
- Untertitel: ein kurzer Satz oder leer

Einstellungen > Lesen:
- Sichtbarkeit für Suchmaschinen: "Suchmaschinen davon abhalten, diese Website zu indexieren" NICHT anhaken

Der Core gibt keine Meta-Description aus, der Untertitel ist also keine. In aktuellen Installationen ist das Feld anfangs leer, und Themes zeigen es eventuell im Header oder im Titel. Die Meta-Description kommt von einem SEO-Plugin oder vom Theme. Die Checkbox zur Sichtbarkeit für Suchmaschinen liegt unter Lesen, nicht unter Allgemein, und solange sie angehakt ist, schaltet WordPress auch die eigene Sitemap ab.

#SEO-freundliche Permalink-Struktur

Einstellungen > Permalinks > Beitragsname

#XML-Sitemap

add_filter( 'wp_sitemaps_post_types', function ( $post_types ) {
    unset( $post_types['portfolio'] ); // Inhaltstyp aus der Sitemap entfernen
    return $post_types;
} );

Die Core-Sitemap unter /wp-sitemap.xml ist seit WordPress 5.5 standardmäßig aktiv, solange die Website für Suchmaschinen sichtbar ist. Sie enthält alle öffentlichen Inhaltstypen, auch eigene, die alte Zeile $post_types[] = 'portfolio' war also überflüssig und zudem falsch: Das Array enthält WP_Post_Type-Objekte mit dem Namen als Schlüssel. Nützlich ist der Filter in umgekehrter Richtung, um einen Typ aus der Sitemap zu nehmen.

#Grundlegende Bildoptimierung für SEO

Ein verbreitetes Snippet füllt leere ALT-Attribute mit dem Titel des Anhangs und erzeugt Titel aus Dateinamen. Letzteres erledigt bereits der Core: media_handle_upload() übernimmt den Titel des Anhangs aus dem Dateinamen. Ersteres erzeugt ALT-Texte wie “IMG_2041”, die ein Screenreader vorliest und die nichts über das Bild sagen. Schreiben Sie den ALT-Text pro Bild in der Mediathek und lassen Sie ihn bei rein dekorativen Bildern leer.

#Backups von WordPress erstellen

#Automatische Datenbank-Backups

# crontab -e (Benutzer der Website, nicht root)
15 3 * * * cd /var/www/example/public && wp db export /home/example/backups/db-$(date +\%F).sql --quiet && find /home/example/backups -name 'db-*.sql' -mtime +7 -delete

Das frühere MU-Plugin schrieb Dumps nach wp-content/uploads/backups, in einen öffentlichen Ordner, aus dem jeder die Datenbank herunterladen kann, der den datumsbasierten Dateinamen errät. Außerdem übergab es das Datenbankpasswort in der Befehlszeile von mysqldump, wo andere Benutzer des Servers es in der Prozessliste sehen, und es hing von WP-Cron ab, das nur bei Besuchen auf der Website läuft. Ein System-Cronjob mit wp db export schreibt außerhalb des Web-Roots und läuft pünktlich.

#Externe Backups einrichten

Empfohlene Lösungen:

1. UpdraftPlus: Die kostenlose Version reicht für kleine Websites
2. BlogVault: kostenpflichtig, aber sehr zuverlässig
3. WPvivid: eine gute kostenlose Alternative

Konfiguration:

• Tägliches Backup (Datenbank)
• Wöchentliches Backup (vollständig)
• Aufbewahrung: mindestens 30 Tage
• Externer Speicherort: Google Drive, Dropbox, S3

#SMTP in WordPress konfigurieren

#SMTP statt mail()

// In wp-config.php oder einem MU-Plugin
define('SMTP_USER', '[email protected]');
define('SMTP_PASS', 'your-password');
define('SMTP_HOST', 'smtp.gmail.com');
define('SMTP_PORT', '587');
define('SMTP_SECURE', 'tls');
define('SMTP_FROM', '[email protected]');
define('SMTP_NAME', 'Ihre Website');

// Im MU-Plugin
add_action('phpmailer_init', function($phpmailer) {
    $phpmailer->isSMTP();
    $phpmailer->Host = SMTP_HOST;
    $phpmailer->SMTPAuth = true;
    $phpmailer->Username = SMTP_USER;
    $phpmailer->Password = SMTP_PASS;
    $phpmailer->SMTPSecure = SMTP_SECURE;
    $phpmailer->Port = SMTP_PORT;
    $phpmailer->From = SMTP_FROM;
    $phpmailer->FromName = SMTP_NAME;
});

#Test-E-Mail aus WordPress senden

add_action( 'admin_init', function () {
    if ( isset( $_GET['test_email'] ) && current_user_can( 'manage_options' ) ) {
        $sent = wp_mail( get_option( 'admin_email' ), 'Test email', 'Dies ist eine Testnachricht aus WordPress.' );
        wp_die( $sent ? 'OK' : 'wp_mail() returned false' );
    }
} );

admin_init feuert auch bei Anfragen an admin-ajax.php von nicht angemeldeten Besuchern, ohne die Berechtigungsprüfung könnte also jeder die Website zum Mailversand bringen. Mit WP-CLI ist derselbe Test eine Zeile: wp eval 'var_dump( wp_mail( get_option( "admin_email" ), "Test", "Test" ) );'.

#WordPress-Monitoring und Fehlerprotokollierung

#Fehlerprotokollierung

// In wp-config.php
define('WP_DEBUG', false);
define('WP_DEBUG_LOG', '/var/log/wp-errors.log'); // Außerhalb des öffentlichen Verzeichnisses
define('WP_DEBUG_DISPLAY', false);

// SQL-Abfragen protokollieren (nur im Debug-Modus)
// define('SAVEQUERIES', true);

#Uptime-Monitoring

Empfohlene Werkzeuge:

• UptimeRobot
• Pingdom (kostenpflichtig, aber umfangreicher)
• Better Uptime (moderne Alternative)

#Admin-Logins und Beitragsänderungen protokollieren

// Im MU-Plugin: wp-content/mu-plugins/activity-log.php
<?php
/* Plugin Name: Activity Log */

add_action('wp_login', function($user_login, $user) {
    error_log('User logged in: ' . $user_login . ' from IP: ' . $_SERVER['REMOTE_ADDR']);
}, 10, 2);

add_action('save_post', function($post_id, $post, $update) {
    if ($update && $post->post_status === 'publish') {
        error_log('Post updated: ' . $post->post_title . ' by user: ' . get_current_user_id());
    }
}, 10, 3);

#Was Sie vor dem Start einer WordPress-Website prüfen sollten

#Checkliste vor dem Livegang

• Alle SEO-Einstellungen korrekt
• Sitemap erzeugt
• Google Search Console eingerichtet
• Google Analytics installiert
• Datenschutzerklärung und AGB hinzugefügt
• Kontaktformulare getestet
• E-Mail-Versand funktioniert
• SSL funktioniert (HTTPS)
• Weiterleitungen zwischen www und ohne www eingerichtet
• Backup erstellt
• Caching-Plugins konfiguriert (optional)
• CDN konfiguriert (optional)
• Performance-Tests durchgeführt (PageSpeed Insights)
• Tests der mobilen Darstellung
• Tests in verschiedenen Browsern
• 404-Seite eingerichtet
• Favicon hinzugefügt

#Prüfsummen und Dateizugriff mit WP-CLI und curl testen

# WP-CLI-Tests
wp core verify-checksums
wp plugin verify-checksums --all
wp db check

# Sicherheitstests
curl -I https://ihre-website.de/wp-admin/install.php # liefert die Seite "Bereits installiert", sofern der Server sie nicht sperrt
curl -I https://ihre-website.de/wp-config.php # 403 mit der <Files>-Regel; ohne sie eine leere Seite

#Welche WordPress-Einstellungen Sie nach der Installation ändern sollten

Drei Bildschirme unter Einstellungen enthalten Standardwerte, die zählen, bevor der erste Besucher kommt. Die Dokumentation des Bildschirms Allgemein beschreibt jedes Feld.

Allgemein. Wählen Sie die Zeitzone als Stadt, nicht als UTC-Versatz. Eine Stadt folgt der Sommerzeit, ein fester Versatz nicht, und geplante Beiträge erscheinen dann ein halbes Jahr lang eine Stunde daneben. Die hier eingestellte Sprache der Website ist die Sprache des Dashboards. Eine neue Administrator-E-Mail-Adresse gilt nicht sofort: WordPress schickt einen Bestätigungslink an die neue Adresse und lässt die alte aktiv, bis der Link geklickt wird, also nehmen Sie ein Postfach, das jemand liest. Lassen Sie die Mitgliedschaft (“Jeder kann sich registrieren”) ausgeschaltet, es sei denn, die Website braucht eine offene Registrierung, und wenn ja, belassen Sie Abonnent als Standardrolle für neue Benutzer.

Lesen. Hier liegt die Checkbox zur Sichtbarkeit für Suchmaschinen. Staging-Kopien sollten sie angehakt haben, die Produktion nicht. Die Einstellung steht in der Datenbank und wandert mit jeder Kopie der Datenbank mit: Prüfen Sie sie nach jedem Umzug von Staging in die Produktion.

Diskussion. Eine neue Installation hat Kommentare und Pingbacks standardmäßig geöffnet, die manuelle Freigabe von Kommentaren ausgeschaltet und “Der Kommentarautor muss bereits einen freigegebenen Kommentar haben” eingeschaltet. Auf einer Firmenwebsite ohne Kommentare schließen Sie sie hier vor der Veröffentlichung. Die Einstellung gilt für neue Beiträge; bestehende behalten ihren eigenen Status.

#Den Website-Zustand nach der WordPress-Installation lesen

Werkzeuge > Website-Zustand führt eine Reihe von Prüfungen aus und sortiert die Ergebnisse in kritische Probleme und empfohlene Verbesserungen (Dokumentation des Bildschirms Site Health). Auf einer neuen Website sind die Prüfungen nützlich, die die Einstellungen aus diesem Artikel berühren:

• Debugging aktiviert. Mit eingeschaltetem WP_DEBUG_LOG wird die Prüfung kritisch, wenn das PHP-Fehlerprotokoll im WordPress-Verzeichnis liegt, weil es sich dann herunterladen lässt. Deshalb zeigt der Protokollpfad weiter oben in diesem Artikel aus dem öffentlichen Ordner heraus.
• Sichtbarkeit für Suchmaschinen. Wird gemeldet, solange “Suchmaschinen davon abhalten” angehakt ist (Prüfung seit WordPress 6.9).
• Offene Registrierung mit privilegierter Standardrolle. Wird gemeldet, wenn sich jeder mit einer Rolle über Abonnent registrieren kann (seit WordPress 7.0).
• Hintergrund-Updates, automatische Updates für Plugins und Themes, geplante Ereignisse, Loopback-Anfrage. Schlagen diese fehl, laufen weder automatische Updates noch WP-Cron-Aufgaben.
• HTTPS-Status, persistenter Objekt-Cache, Seiten-Cache. Prüfungen des Hostings. Die beiden Cache-Prüfungen sind Empfehlungen, keine Fehler.

Der Tab Bericht listet Serverdaten auf (PHP-Version und Erweiterungen, Datenbankversion, Unterstützung des Bildeditors, Konstanten wie WP_DEBUG_LOG und WP_ENVIRONMENT_TYPE) und hat eine Schaltfläche, die alles in die Zwischenablage kopiert. In ein Ticket eingefügt, spart das eine Fragerunde mit dem Hoster.

#Wie automatische Updates auf einer neuen WordPress-Website funktionieren

Es gibt drei Ebenen, die an verschiedenen Stellen eingestellt werden (Configuring automatic background updates):

• Kleinere Core-Versionen (Sicherheit und Wartung) installieren sich seit WordPress 3.7 selbst.
• Größere Core-Versionen. Auf Websites, die mit WordPress 5.6 oder neuer installiert wurden, startet die Option auto_update_core_major als aktiviert. Websites, die von einer älteren Version aktualisiert wurden, haben sie ungesetzt. Die Konstante WP_AUTO_UPDATE_CORE überschreibt beides: true für alle Versionen, 'minor' nur für kleinere Versionen, false schaltet Core-Updates im Hintergrund ab.
• Plugins und Themes. Automatische Updates sind standardmäßig aus und werden pro Plugin oder Theme auf den Bildschirmen Plugins und Themes eingeschaltet, eine Funktion aus WordPress 5.5.

DISALLOW_FILE_MODS (Punkt 5 der Checkliste) blendet nicht nur die Schaltflächen zum Installieren und Aktualisieren aus. Der Core prüft vor jedem Hintergrund-Update wp_is_file_mod_allowed( 'automatic_updater' ), die Konstante stoppt also auch automatische Sicherheitsversionen. Das passt, wenn jedes Update per Deployment ausgeliefert wird. Ohne einen solchen Prozess bleibt die Website auf der Version, mit der sie ausgeliefert wurde, bis jemand erneut deployt.

#Sollte man Anwendungspasswörter in WordPress deaktivieren

Anwendungspasswörter, eingeführt mit WordPress 5.6, erlauben einem externen Werkzeug, sich an der REST API mit dem Benutzernamen und einem generierten Passwort statt des Kontopassworts anzumelden (Dokumentation zu Application Passwords). Jeder Benutzer legt sie im eigenen Profil an und widerruft sie dort. Ein neues Passwort wird einmal angezeigt, als Hash gespeichert und mit Datum und IP-Adresse der letzten Nutzung aufgeführt. Der Core bietet die Funktion nur auf Websites mit HTTPS an oder wenn WP_ENVIRONMENT_TYPE den Wert local hat.

Lassen Sie sie eingeschaltet, wenn eine mobile App, ein Deployment-Werkzeug oder eine Integration mit der REST API spricht. Auf einer Website ohne all das schaltet ein Filter sie für alle Benutzer ab:

add_filter( 'wp_is_application_passwords_available', '__return_false' );

Nach einem vermuteten Einbruch widerrufen Sie die Anwendungspasswörter zusätzlich zum Austausch der Salt-Schlüssel. Neue Schlüssel beenden alle Anmeldesitzungen, Anwendungspasswörter werden aber mit einem festen Schlüssel gehasht, der nicht von den Salts abhängt, und funktionieren daher weiter, bis jemand sie widerruft.

#Die Datenschutzerklärung in WordPress einrichten

Der Installer legt eine Seite “Datenschutzerklärung” als Entwurf an und weist sie unter Einstellungen > Datenschutz zu, einem Bildschirm, der mit WordPress 4.9.6 kam (Dokumentation der Datenschutz-Einstellungen). Der Entwurf enthält vorgeschlagene Überschriften und Beispieltext, keine fertige Erklärung. Derselbe Bildschirm erlaubt die Wahl einer anderen Seite und verlinkt den Leitfaden zur Datenschutzerklärung, in dem der Core und Plugins, die über wp_add_privacy_policy_content() Textvorschläge registrieren, beschreiben, was sie speichern.

Daraus folgen zwei Dinge. Der Entwurf ist nicht öffentlich, bis ihn jemand bearbeitet und veröffentlicht. Und Themes geben den Link zur Erklärung über the_privacy_policy_link() aus, das nichts ausgibt, solange die zugewiesene Seite unveröffentlicht ist; ein “fehlender” Link im Footer bedeutet also meist eine unveröffentlichte Seite. Werkzeuge > Personenbezogene Daten exportieren und Werkzeuge > Personenbezogene Daten löschen bearbeiten Auskunfts- und Löschanfragen zu den Daten, die WordPress und mitwirkende Plugins speichern.

#Zusammenfassung: die Checkliste mit 50 Punkten

#Sicherheit (1-15)

1. ✅ Eigenes Tabellenpräfix setzen (bei der Installation, über $table_prefix)
2. ✅ Starke Passwörter festlegen (mind. 12 Zeichen)
3. ✅ Benutzernamen admin ändern
4. ✅ Dateieditor im Backend deaktivieren
5. ✅ Plugin-Installation sperren (optional; stoppt auch automatische Updates)
6. ✅ SSL im Admin-Bereich erzwingen
7. ✅ wp-config.php per .htaccess schützen
8. ✅ Zugriff auf Verzeichnisse sperren (no indexes)
9. ✅ XML-RPC einschränken (der Filter deckt nur authentifizierte Methoden ab; für Jetpack beibehalten)
10. ✅ WordPress-Version verbergen
11. ✅ Anmeldeversuche begrenzen
12. ✅ Zwei-Faktor-Authentifizierung einrichten (Plugin Two Factor)
13. ✅ Authentifizierungsschlüssel (Salts) regelmäßig rotieren
14. ✅ SSL-Zertifikat installieren
15. ✅ Schutz auf Serverebene einrichten (Firewall, Begrenzung der Anmeldeversuche)

#Performance (16-25)

16. ✅ Beitragsrevisionen begrenzen (5-10)
17. ✅ Emoji deaktivieren
18. ✅ Ungenutzte Funktionen deaktivieren (XML-RPC, RSD)
19. ✅ Bildgrößen optimieren
20. ✅ Prüfen, ob Lazy Loading aktiv ist (Standard seit 5.5)
21. ✅ Cache einrichten (Object Cache, Page Cache)
22. ✅ Heartbeat API optimieren
23. ✅ GZIP/Brotli-Komprimierung aktivieren
24. ✅ CDN einrichten (optional)
25. ✅ Datenbank optimieren (automatische Bereinigung)

#SEO (26-35)

26. ✅ Permalink-Struktur “Beitragsname” einstellen
27. ✅ Titel und Untertitel festlegen (der Untertitel ist keine Meta-Description)
28. ✅ Core-Sitemap unter /wp-sitemap.xml prüfen
29. ✅ Website zur Google Search Console hinzufügen
30. ✅ Google Analytics / GA4 einrichten
31. ✅ ALT-Text für jedes Bild schreiben
32. ✅ Kategoriestruktur anlegen
33. ✅ Breadcrumbs einrichten
34. ✅ Organization-Schema hinzufügen
35. ✅ Open-Graph-Meta-Tags vorbereiten

#Backups (36-42)

36. ✅ Automatische Datenbank-Backups einrichten
37. ✅ Wöchentliche Vollbackups einrichten
38. ✅ Backups an einem externen Ort speichern
39. ✅ Wiederherstellung aus dem Backup testen
40. ✅ Aufbewahrungsdauer festlegen (mind. 30 Tage)
41. ✅ Wiederherstellungsablauf dokumentieren
42. ✅ Integrität der Backups regelmäßig prüfen

#Inhalte und Funktionen (43-50)

43. ✅ Grundlegende Seiten anlegen (Über uns, Kontakt, Datenschutzerklärung)
44. ✅ Navigationsmenüs einrichten
45. ✅ Alle Formulare testen
46. ✅ SMTP für den E-Mail-Versand einrichten
47. ✅ Eigene 404-Seite erstellen
48. ✅ Favicon und PWA-Icons hinzufügen
49. ✅ Performance-Tests durchführen
50. ✅ Konfiguration dokumentieren

Werfen Sie einen Blick auf unser WordPress-Sicherheitsaudit, wenn Sie Risiken und Schutzmaßnahmen Ihrer Website ordnen möchten.

#Unterschiede in wp-config.php zwischen Staging und Produktion

Dieser Leitfaden setzt WP_DEBUG zweimal mit unterschiedlichen Werten: im Abschnitt zum Debugging auf true, im Abschnitt zum Monitoring auf false. Beide Varianten sind richtig, jede für eine andere Umgebung. Deshalb sollte dieselbe Kopie von wp-config.php nicht unverändert auf Staging und Produktion landen. Bevor Sie die Datei zwischen Servern verschieben, gehen Sie diese Konstanten durch:

• WP_ENVIRONMENT_TYPE: staging auf der Testkopie, production auf der Live-Website. Von diesem Wert hängt jede Bedingung ab, die auf wp_get_environment_type() aufbaut.
• WP_DEBUG: auf Staging aktiviert, in Produktion deaktiviert. WP_DEBUG_DISPLAY bleibt an beiden Orten false, und das Log liegt außerhalb des öffentlichen Verzeichnisses.
• SAVEQUERIES: nur während der Suche nach langsamen Abfragen, nie in Produktion.
• DISALLOW_FILE_MODS: sperrt in Produktion die Installation und Aktualisierung von Plugins im Backend, Updates laufen also über das Deployment oder WP-CLI. Klären Sie das mit dem Kunden, bevor er den fehlenden Aktualisierungsbutton bemerkt.
• Authentifizierungsschlüssel: für jede Installation zufällig erzeugt. Eine Kopie der Produktion auf Staging bekommt einen eigenen Satz, und die produktiven Schlüssel rühren Sie nicht an, weil ihre Änderung alle Benutzer abmeldet.

Führen Sie nach dem Verschieben der Datei wp core verify-checksums und wp plugin verify-checksums --all aus dem Abschnitt zu den Tests vor dem Livegang aus.