WordPress después de la instalación: lista de verificación... | WPPoland

Mariusz Szatkowski

WordPress después de la instalación: lista de verificación de 50 puntos para 2026

Última verificación: 13 de octubre de 2026

25 min de lectura

Guía

500+ proyectos WP

Auditor de seguridad

La “famosa instalación en 5 minutos” es un eslogan de marketing, no un estándar profesional. Una instalación predeterminada de WordPress es “habladora”, poco optimizada y a menudo insegura.

Como desarrolladores no nos limitamos a “instalar” WordPress. Lo preparamos para funcionar en un entorno concreto. Esta guía cubre las constantes de configuración clave y las técnicas de refuerzo de seguridad que deberían formar parte de la base de cualquier proyecto de cliente en 2026.

#Configurar wp-config.php después de instalar WordPress

Es el cerebro de tu instalación. Deja de tenerlo con la configuración predeterminada.

#Definir WP_ENVIRONMENT_TYPE en wp-config.php

Desde WordPress 5.5, WP_ENVIRONMENT_TYPE es el estándar. Úsalo para evitar que los errores de desarrollo lleguen a producción.

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

Después, en tu código:

if ( wp_get_environment_type() === 'production' ) {
    // Activar caché, desactivar errores
}

#Desactivar el editor de archivos y forzar SSL en wp-config.php

Evita que los clientes (o los atacantes) rompan el sitio desde el panel de administración.

// Desactivar el editor de archivos (editor de temas/plugins)
define( 'DISALLOW_FILE_EDIT', true );

// Bloquear la instalación/actualización de plugins (útil en despliegues inmutables)
define( 'DISALLOW_FILE_MODS', true );

// Forzar SSL en la administración
define( 'FORCE_SSL_ADMIN', true );

#Cómo limitar las revisiones de entradas en WordPress

El asesino de la base de datos. ¿De verdad necesitas 100 versiones de la página “Sobre nosotros”?

define( 'WP_POST_REVISIONS', 10 ); // Conservar las últimas 10
// O
define( 'WP_POST_REVISIONS', false ); // Desactivar por completo (no recomendado)

#Cómo activar WP_DEBUG_LOG sin mostrar errores

Nunca muestres errores en el frontend. Regístralos.

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', '/tmp/wp-errors.log' ); // ¡Saca el registro del directorio público!
define( 'WP_DEBUG_DISPLAY', false );

// Registrar consultas SQL para depurar el rendimiento (¡desactívalo en producción!)
define( 'SAVEQUERIES', false );

#Cómo desactivar los emoji y XML-RPC en WordPress

WordPress trae funciones que el 90% de los sitios empresariales no necesita: emoji, oEmbeds y XML-RPC.

No instales un plugin para desactivarlas. Crea un plugin must-use (wp-content/mu-plugins/lean-core.php).

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

// 1. Desactivar los emoji (ahorra una petición HTTP)
remove_action( 'wp_head', 'print_emoji_detection_script', 7 );
remove_action( 'wp_print_styles', 'print_emoji_styles' );

// 2. Desactivar XML-RPC (seguridad)
add_filter( 'xmlrpc_enabled', '__return_false' );

// 3. Eliminar la versión de WP (seguridad por oscuridad)
remove_action( 'wp_head', 'wp_generator' );

// 4. Desactivar los feeds RSS (si construyes una web corporativa)
// function wppoland_disable_feed() {
//    wp_die( 'No hay feed, ¡visita nuestra página de inicio!' );
// }
// add_action('do_feed', 'wppoland_disable_feed', 1);

Pese a su nombre, el filtro xmlrpc_enabled del punto 2 solo desactiva los métodos XML-RPC que requieren autenticación, como la publicación. Los pingbacks y otros métodos sin autenticación siguen respondiendo en xmlrpc.php. Bloquear el archivo entero corresponde al servidor web, y solo si nada lo usa: Jetpack, por ejemplo, se conecta por XML-RPC.

#Cambiar las claves salt en wp-config.php

Ya conoces las claves de autenticación de wp-config.php.

define('AUTH_KEY',         'escribe aquí tu frase única');
// ...

Dato: cambiarlas cierra al instante la sesión de todos los usuarios. Es la “opción nuclear” si el sitio ha sido hackeado. Consejo profesional: automatiza su rotación con un script de CLI o con Vault si gestionas sitios enterprise.

#Qué configurar en wp-config.php antes de lanzar el sitio

Antes del lanzamiento:

Establece WP_ENVIRONMENT_TYPE en production.
Establece DISALLOW_FILE_EDIT en true.
Limita WP_POST_REVISIONS.
Mueve WP_DEBUG_LOG a una carpeta privada.
Desactiva los emoji/XML-RPC por código.

Una instancia de WordPress bien configurada es silenciosa, segura y rápida.

#Qué enlaces permanentes configurar en WordPress

#La estructura de enlaces permanentes óptima

Ajustes > Enlaces permanentes > Nombre de la entrada

Por qué:

URL más cortas y legibles
Mejor para el SEO (palabras clave en la URL)
Más fáciles de recordar y compartir

Una instalación nueva suele traer ya enlaces permanentes legibles. Si el servidor admite la reescritura de URL, el instalador establece /%year%/%monthnum%/%day%/%postname%/ (la función del núcleo wp_install_maybe_enable_pretty_permalinks()). Cambia a Nombre de la entrada antes de publicar la primera entrada: cambiar la estructura en un sitio en marcha cambia todas las URL de las entradas, y las direcciones antiguas necesitan redirecciones.

#Estructura de categorías y etiquetas

Crea las categorías básicas (3-7 principales)
Define la jerarquía (categorías superiores y subcategorías)
Establece una categoría predeterminada (no “Sin categoría”)
Planifica una estrategia de etiquetas (opcional, 5-10 etiquetas por entrada)

#Ajustes de medios y tamaños de imagen en WordPress

#Tamaños de imagen

Ajustes > Medios

Ajustes recomendados:

Miniatura: 150x150px (marca “Recortar la miniatura a las dimensiones exactas”)
Mediano: 300x300px
Grande: 1024x1024px
Tamaño completo: siempre disponible

#Optimización automática de imágenes

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

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

Dos líneas habituales en copias de este fragmento faltan a propósito. wp_lazy_loading_enabled ya devuelve true por defecto (loading="lazy" nativo desde WordPress 5.5), y el filtro wp_image_editors solo fija el orden en que WordPress prueba Imagick y GD, que es el orden predeterminado. Ninguno de los dos optimiza nada al subir. Las imágenes de más de 2560 px de ancho o alto ya se reducen al subirlas mediante el filtro big_image_size_threshold.

#Cómo activar la subida en WebP en WordPress

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

El fragmento no usa wp_upload_image_mime_transforms, un filtro que no existe en el núcleo actual de WordPress. image_editor_output_format existe desde WordPress 5.8 y asigna a cada tipo de origen el tipo en que WordPress guarda los tamaños generados; desde la 6.7 su valor por defecto ya convierte HEIC y HEIF a JPEG, y el fragmento conserva esas entradas. Imagick o GD en el servidor tienen que admitir WebP. Herramientas > Salud del sitio > Información > Gestión de medios muestra qué formatos admite.

#Cómo proteger WordPress después de la instalación

#Cambiar el prefijo predeterminado de las tablas

Durante la instalación: Introduce un prefijo personalizado en lugar de wp_ (por ejemplo x7k9_, mysite_, proj23_)

Después de la instalación (avanzado):

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

RENAME TABLE wp_posts TO x7k9_posts;
RENAME TABLE wp_options TO x7k9_options;
-- ... repetir para todas las tablas

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 no tiene una constante DB_PREFIX: el prefijo está en la variable $table_prefix. Renombrar solo las tablas deja fuera a los administradores, porque los roles y capacidades se guardan con claves con prefijo en options (wp_user_roles) y usermeta (wp_capabilities, wp_user_level). Eso es lo que corrigen las dos sentencias UPDATE. La guía Hardening WordPress trata el prefijo propio como oscuridad: puede bloquear algunos ataques automatizados de inyección SQL que dan por hecho wp_, y no sustituye a corregir el código vulnerable.

#Proteger el archivo wp-config.php

# .htaccess (raíz, al principio del archivo)
<Files "wp-config.php">
Require all denied
</Files>

Order allow,deny es sintaxis de Apache 2.2 y en Apache 2.4 solo funciona con el módulo de compatibilidad. La guía Hardening WordPress da la forma Require all denied de arriba y la coloca al principio del .htaccess raíz. Nginx ignora los archivos .htaccess, así que en Nginx la misma regla va en el bloque server.

#Bloquear el acceso a directorios

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

# .htaccess (raíz, fuera de # BEGIN WordPress y # 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 reescribe todo lo que está entre los marcadores # BEGIN WordPress y # END WordPress cada vez que se guardan los enlaces permanentes, así que este bloque va fuera de ellos, en el .htaccess raíz y no en wp-includes/: las rutas de las reglas son relativas a la raíz del sitio. En multisitio, la línea ^wp-includes/[^/]+\.php$ impide que ms-files.php sirva imágenes, y la guía Hardening WordPress indica quitar esa línea allí, a costa de algo de protección.

#Limitar los intentos de inicio de sesión

<?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', 'Demasiados intentos de inicio de sesión. Inténtalo de nuevo dentro de una hora.' );
    }
    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' );

Contar los fallos en wp_login_failed y llamar a wp_die() allí no funciona. Ese hook se ejecuta después de comprobar la contraseña, así que una contraseña correcta seguía entrando tras cinco fallos. El filtro authenticate con prioridad 30 se ejecuta después de que el núcleo compruebe usuario y contraseña, y un WP_Error devuelto ahí detiene el inicio de sesión. Detrás de una CDN o de un proxy inverso, REMOTE_ADDR contiene la dirección del proxy y todos los visitantes compartirían un único contador: en esos casos limita los inicios de sesión en el proxy o con fail2ban en el servidor.

#Autenticación de dos factores (2FA)

El núcleo de WordPress no tiene segundo factor. El plugin Two Factor, publicado en WordPress.org bajo la cuenta de WordPress.org, añade aplicaciones de autenticación (TOTP), códigos por correo y códigos de respaldo, y cada usuario lo activa en su propio perfil. La guía Hardening WordPress recomienda la autenticación en dos pasos como capa adicional a la contraseña. El fragmento de abajo hace algo más modesto: rechaza contraseñas de menos de 12 caracteres al guardar un perfil.

// Exigir contraseñas seguras
add_action('user_profile_update_errors', function($errors) {
    $password = $_POST['pass1'];
    if (!empty($password) && strlen($password) < 12) {
        $errors->add('password_error', 'La contraseña debe tener al menos 12 caracteres.');
    }
});

#Cómo acelerar WordPress después de la instalación

#Optimización básica de la base de datos

// En wp-config.php
// Limitar las revisiones de entradas
define('WP_POST_REVISIONS', 10);

// Vaciar la papelera automáticamente a los 7 días
define('EMPTY_TRASH_DAYS', 7);

// Desactivar el editor de archivos (seguridad + rendimiento)
define('DISALLOW_FILE_EDIT', true);

#Limpieza de la base de datos

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

El mu-plugin eliminado borraba transients comparando option_value con la hora actual, pero la caducidad se guarda en filas _transient_timeout_ aparte, así que borraba filas equivocadas. El núcleo ya hace este trabajo: wp-admin/admin.php programa un evento diario delete_expired_transients (que se omite cuando una caché de objetos persistente guarda los transients), y un evento diario wp_scheduled_auto_draft_delete elimina los borradores automáticos de más de siete días. Con WP_POST_REVISIONS definido, las revisiones tampoco necesitan un cron de borrado. Ejecuta a mano los comandos de WP-CLI de arriba cuando una base de datos parezca inflada.

#Optimización de la Heartbeat API

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

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

El intervalo por defecto de Heartbeat es de 60 segundos (mainInterval en heartbeat.js), no 15, así que el valor anterior de 60 no cambiaba nada. Heartbeat además se ralentiza solo a 120 segundos cuando la pestaña del navegador está oculta. En el editor transporta los bloqueos de entradas, así que un intervalo más largo retrasa el aviso de que otra persona está editando la misma entrada.

#Quitar los enlaces RSD, shortlink y REST API de wp_head

// En un mu-plugin: wp-content/mu-plugins/disable-bloat.php
<?php
/* Plugin Name: Disable Bloat */

// Desactivar los emoji
remove_action('wp_head', 'print_emoji_detection_script', 7);
remove_action('wp_print_styles', 'print_emoji_styles');

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

// Desactivar el enlace RSD
remove_action('wp_head', 'rsd_link');

// Desactivar el enlace de Windows Live Writer
remove_action('wp_head', 'wlwmanifest_link');

// Desactivar el enlace corto
remove_action('wp_head', 'wp_shortlink_wp_head');

// Desactivar el enlace de la REST API (si no la usas)
remove_action('wp_head', 'rest_output_link_wp_head');

#Ajustes básicos de SEO en WordPress

#Título del sitio, descripción corta y visibilidad en buscadores

Ajustes > Generales:
- Título del sitio: [Tu marca]
- Descripción corta: una frase breve, o vacía

Ajustes > Lectura:
- Visibilidad en los motores de búsqueda: deja DESMARCADO "Disuade a los motores de búsqueda de indexar este sitio"

El núcleo no imprime ninguna meta description, así que la descripción corta no lo es. En las instalaciones actuales el campo empieza vacío, y los temas pueden mostrarlo en la cabecera o en el título. La meta description la pone un plugin de SEO o el tema. La casilla de visibilidad en buscadores está en Lectura, no en Generales, y mientras está marcada WordPress también desactiva su propio mapa del sitio.

#Estructura de enlaces permanentes amigable para el SEO

Ajustes > Enlaces permanentes > Nombre de la entrada

#Mapa del sitio (XML Sitemap)

add_filter( 'wp_sitemaps_post_types', function ( $post_types ) {
    unset( $post_types['portfolio'] ); // quitar un tipo de contenido del mapa del sitio
    return $post_types;
} );

El mapa del sitio del núcleo en /wp-sitemap.xml está activo por defecto desde WordPress 5.5, siempre que el sitio sea visible para los buscadores. Incluye todos los tipos de contenido públicos, también los personalizados, así que la antigua línea $post_types[] = 'portfolio' sobraba y además era incorrecta: el array contiene objetos WP_Post_Type indexados por nombre. El filtro sirve para lo contrario, para sacar un tipo del mapa del sitio.

#Optimización básica de imágenes para SEO

Un fragmento habitual rellena los atributos ALT vacíos con el título del adjunto y genera títulos a partir del nombre del archivo. Lo segundo ya lo hace el núcleo: media_handle_upload() toma el título del adjunto del nombre del archivo. Lo primero produce textos ALT como “IMG_2041”, que el lector de pantalla anuncia y que no dicen nada de la imagen. Escribe el texto ALT de cada imagen en la biblioteca de medios y déjalo vacío en las imágenes puramente decorativas.

#Cómo hacer copias de seguridad de WordPress

#Copias automáticas de la base de datos

# crontab -e (usuario del sitio, no 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

El mu-plugin anterior guardaba los volcados en wp-content/uploads/backups, una carpeta pública desde la que cualquiera que adivine el nombre basado en la fecha puede descargar la base de datos. También pasaba la contraseña de la base de datos en la línea de comandos de mysqldump, donde otros usuarios del servidor la ven en la lista de procesos, y dependía de WP-Cron, que solo se ejecuta cuando alguien visita el sitio. Una tarea cron del sistema con wp db export escribe fuera de la raíz web y se ejecuta a su hora.

#Configurar copias externas

Soluciones recomendadas:

UpdraftPlus: la versión gratuita basta para sitios pequeños
BlogVault: de pago, pero muy fiable
WPvivid: una buena alternativa gratuita

Configuración:

Copia diaria (base de datos)
Copia semanal (completa)
Retención: mínimo 30 días
Ubicación externa: Google Drive, Dropbox, S3

#Configurar SMTP en WordPress

#SMTP en lugar de mail()

// En wp-config.php o en un 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', 'Tu sitio');

// En el 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;
});

#Cómo enviar un correo de prueba desde WordPress

add_action( 'admin_init', function () {
    if ( isset( $_GET['test_email'] ) && current_user_can( 'manage_options' ) ) {
        $sent = wp_mail( get_option( 'admin_email' ), 'Test email', 'Este es un mensaje de prueba enviado desde WordPress.' );
        wp_die( $sent ? 'OK' : 'wp_mail() returned false' );
    }
} );

admin_init también se dispara en las peticiones a admin-ajax.php de visitantes sin sesión iniciada, así que sin la comprobación de capacidad cualquiera podría hacer que el sitio enviara correo. Con WP-CLI la misma prueba ocupa una línea: wp eval 'var_dump( wp_mail( get_option( "admin_email" ), "Test", "Test" ) );'.

#Monitorización de WordPress y registro de errores

#Registro de errores

// En wp-config.php
define('WP_DEBUG', false);
define('WP_DEBUG_LOG', '/var/log/wp-errors.log'); // Fuera del directorio público
define('WP_DEBUG_DISPLAY', false);

// Registro de consultas SQL (solo en modo de depuración)
// define('SAVEQUERIES', true);

#Monitorización del tiempo de actividad

Herramientas recomendadas:

UptimeRobot
Pingdom (de pago, pero más avanzado)
Better Uptime (alternativa moderna)

#Registrar inicios de sesión y cambios en entradas

// En un 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);

#Qué revisar antes de lanzar un sitio WordPress

#Lista de verificación antes del lanzamiento

#Probar checksums y acceso a archivos con WP-CLI y curl

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

# Pruebas de seguridad
curl -I https://tu-sitio.es/wp-admin/install.php # devuelve la página "Ya instalado" salvo que el servidor la bloquee
curl -I https://tu-sitio.es/wp-config.php # 403 con la regla <Files>; sin ella, una página vacía

#Qué ajustes de WordPress cambiar después de la instalación

Tres pantallas de Ajustes contienen valores predeterminados que importan antes de que llegue el primer visitante. La documentación de la pantalla Generales describe cada campo.

Generales. Elige la zona horaria como una ciudad y no como un desfase UTC. Una ciudad sigue el horario de verano, un desfase fijo no, y las entradas programadas se publican entonces con una hora de diferencia durante medio año. El idioma del sitio que se fija aquí es el idioma del panel. Una nueva dirección de correo de administración no se aplica al momento: WordPress envía un enlace de confirmación a la nueva dirección y mantiene activa la antigua hasta que se pulsa el enlace, así que usa un buzón que alguien lea. Deja desactivada la opción Miembros (“Cualquiera puede registrarse”) salvo que el sitio necesite registro abierto, y si lo necesita, mantén Suscriptor como perfil predeterminado de los nuevos usuarios.

Lectura. Esta pantalla contiene la casilla de visibilidad en los motores de búsqueda. Las copias de staging deberían tenerla marcada y producción no. El ajuste se guarda en la base de datos, así que viaja con cada copia de la base de datos: compruébalo después de cada paso de staging a producción.

Comentarios. Una instalación nueva tiene los comentarios y los pingbacks abiertos por defecto, la aprobación manual de comentarios desactivada y “El autor del comentario debe tener un comentario previamente aprobado” activado. En una web corporativa sin comentarios, ciérralos aquí antes de publicar. El ajuste se aplica a las entradas nuevas; las existentes conservan su propio estado.

#Cómo interpretar Salud del sitio después de instalar WordPress

Herramientas > Salud del sitio ejecuta una serie de comprobaciones y ordena los resultados en problemas críticos y mejoras recomendadas (documentación de la pantalla Salud del sitio). En un sitio nuevo, las comprobaciones útiles son las que tocan los ajustes de este artículo:

Depuración activada. Con WP_DEBUG_LOG activo, la comprobación pasa a crítica cuando el registro de errores de PHP está dentro del directorio de WordPress, porque entonces se puede descargar. Por eso la ruta del registro, más arriba en este artículo, apunta fuera de la carpeta pública.
Visibilidad en los motores de búsqueda. Se marca mientras “Disuade a los motores de búsqueda” está activado (prueba añadida en WordPress 6.9).
Registro abierto con un perfil predeterminado con privilegios. Se marca cuando cualquiera puede registrarse con un perfil superior a Suscriptor (desde WordPress 7.0).
Actualizaciones en segundo plano, actualizaciones automáticas de plugins y temas, eventos programados, petición loopback. Si fallan, las actualizaciones automáticas y las tareas de WP-Cron no se ejecutan.
Estado de HTTPS, caché de objetos persistente, caché de página. Comprobaciones del alojamiento. Las dos de caché son recomendaciones, no errores.

La pestaña Información enumera los datos del servidor (versión y extensiones de PHP, versión de la base de datos, compatibilidad del editor de imágenes, constantes como WP_DEBUG_LOG y WP_ENVIRONMENT_TYPE) y tiene un botón que copia todo al portapapeles. Pegarlo en un ticket ahorra una ronda de preguntas con el proveedor de alojamiento.

#Cómo funcionan las actualizaciones automáticas en un sitio WordPress nuevo

Hay tres niveles, configurados en lugares distintos (Configuring automatic background updates):

Versiones menores del núcleo (seguridad y mantenimiento): se instalan solas desde WordPress 3.7.
Versiones mayores del núcleo. En los sitios instalados con WordPress 5.6 o posterior, la opción auto_update_core_major empieza activada. Los sitios actualizados desde una versión anterior la tienen sin definir. La constante WP_AUTO_UPDATE_CORE se impone a ambas: true para todas las versiones, 'minor' solo para las menores, false para desactivar las actualizaciones del núcleo en segundo plano.
Plugins y temas. Las actualizaciones automáticas están desactivadas por defecto y se activan por plugin o por tema en las pantallas Plugins y Temas, una función añadida en WordPress 5.5.

DISALLOW_FILE_MODS (punto 5 de la lista) hace algo más que ocultar los botones de instalar y actualizar. El núcleo comprueba wp_is_file_mod_allowed( 'automatic_updater' ) antes de cualquier actualización en segundo plano, así que la constante también detiene las versiones de seguridad automáticas. Está bien cuando cada actualización llega mediante un despliegue. Sin ese proceso, el sitio se queda en la versión con la que se desplegó hasta que alguien despliegue de nuevo.

#Conviene desactivar las contraseñas de aplicación en WordPress

Las contraseñas de aplicación, añadidas en WordPress 5.6, permiten que una herramienta externa se autentique en la REST API con el nombre de usuario y una contraseña generada en lugar de la contraseña de la cuenta (documentación de Application Passwords). Cada usuario las crea y las revoca en su perfil. Una contraseña nueva se muestra una sola vez, se guarda como hash y aparece con la fecha y la IP de su último uso. El núcleo solo ofrece la función en sitios con HTTPS o cuando WP_ENVIRONMENT_TYPE es local.

Déjala activa cuando una app móvil, una herramienta de despliegue o una integración hable con la REST API. En un sitio sin nada de eso, un filtro la desactiva para todos los usuarios:

add_filter( 'wp_is_application_passwords_available', '__return_false' );

Tras una sospecha de intrusión, revoca las contraseñas de aplicación además de cambiar las claves salt. Las claves nuevas cierran todas las sesiones, pero las contraseñas de aplicación se guardan con un hash de clave fija que no depende de las salts, así que siguen funcionando hasta que alguien las revoque.

#Cómo configurar la página de política de privacidad en WordPress

El instalador crea una página “Política de privacidad” como borrador y la asigna en Ajustes > Privacidad, una pantalla añadida en WordPress 4.9.6 (documentación de los ajustes de privacidad). El borrador contiene encabezados sugeridos y texto de ejemplo, no una política terminada. La misma pantalla permite elegir otra página y enlaza a la guía de la política de privacidad, donde el núcleo y los plugins que registran texto sugerido con wp_add_privacy_policy_content() describen qué datos guardan.

De ahí salen dos cosas. El borrador no es público hasta que alguien lo edita y lo publica. Y los temas imprimen el enlace a la política con the_privacy_policy_link(), que no muestra nada mientras la página asignada no esté publicada, así que un enlace del pie que “falta” suele indicar una página sin publicar. Herramientas > Exportar datos personales y Herramientas > Borrar datos personales gestionan las solicitudes de acceso y de supresión de los datos que guardan WordPress y los plugins que colaboran con estas herramientas.

#Resumen: la lista de verificación de 50 puntos

#Seguridad (1-15)

✅ Define un prefijo de tablas propio (al instalar, con $table_prefix)
✅ Usa contraseñas seguras (mín. 12 caracteres)
✅ Cambia el nombre de usuario admin
✅ Desactiva el editor de archivos en el panel
✅ Bloquea la instalación de plugins (opcional; también detiene las actualizaciones automáticas)
✅ Fuerza SSL en el panel de administración
✅ Protege wp-config.php con .htaccess
✅ Bloquea el acceso a directorios (no indexes)
✅ Restringe XML-RPC (el filtro solo cubre métodos con autenticación; mantenlo si usas Jetpack)
✅ Oculta la versión de WordPress
✅ Limita los intentos de inicio de sesión
✅ Configura la autenticación de dos factores (plugin Two Factor)
✅ Rota periódicamente las claves de autenticación (salts)
✅ Instala un certificado SSL
✅ Configura protecciones a nivel de servidor (cortafuegos, límite de intentos de inicio de sesión)

#Rendimiento (16-25)

✅ Limita las revisiones de entradas (5-10)
✅ Desactiva los emoji
✅ Desactiva las funciones que no usas (XML-RPC, RSD)
✅ Optimiza los tamaños de imagen
✅ Comprueba que la carga diferida está activa (por defecto desde la 5.5)
✅ Configura la caché (de objetos, de página)
✅ Optimiza la Heartbeat API
✅ Activa la compresión GZIP/Brotli
✅ Configura una CDN (opcional)
✅ Optimiza la base de datos (limpieza automática)

#SEO (26-35)

✅ Establece la estructura de enlaces permanentes “Nombre de la entrada”
✅ Configura el título y la descripción corta (la descripción corta no es una meta description)
✅ Comprueba el mapa del sitio del núcleo en /wp-sitemap.xml
✅ Añade el sitio a Google Search Console
✅ Configura Google Analytics / GA4
✅ Escribe el texto ALT de cada imagen
✅ Crea la estructura de categorías
✅ Configura las migas de pan (breadcrumbs)
✅ Añade el schema Organization
✅ Prepara las metaetiquetas Open Graph

#Copias de seguridad (36-42)

✅ Configura copias automáticas de la base de datos
✅ Configura copias completas semanales
✅ Guarda las copias en una ubicación externa
✅ Prueba la restauración desde una copia
✅ Fija la retención de las copias (mín. 30 días)
✅ Documenta el procedimiento de restauración
✅ Verifica con regularidad la integridad de las copias

#Contenido y funcionalidad (43-50)

✅ Crea las páginas básicas (Sobre nosotros, Contacto, Política de privacidad)
✅ Configura los menús de navegación
✅ Prueba todos los formularios
✅ Configura SMTP para el correo
✅ Crea una página 404 personalizada
✅ Añade el favicon y los iconos PWA
✅ Realiza pruebas de rendimiento
✅ Documenta la configuración

Consulta nuestra auditoría de seguridad WordPress si quieres poner orden en los riesgos y las protecciones del sitio.

#Diferencias en wp-config.php entre staging y producción

Esta guía define WP_DEBUG dos veces con valores distintos: true en la sección de depuración y false en la de monitorización. Las dos versiones son correctas, cada una para un entorno diferente, y por eso la misma copia de wp-config.php no debería llegar sin cambios a staging y a producción. Antes de mover el archivo entre servidores, repasa estas constantes:

WP_ENVIRONMENT_TYPE: staging en la copia de pruebas, production en el sitio en vivo. Cualquier condición basada en wp_get_environment_type() depende de este valor.
WP_DEBUG: activado en staging, desactivado en producción. WP_DEBUG_DISPLAY se queda en false en ambos sitios y el registro va fuera del directorio público.
SAVEQUERIES: solo mientras buscas consultas lentas, nunca en producción.
DISALLOW_FILE_MODS: en producción bloquea la instalación y actualización de plugins desde el panel, así que las actualizaciones pasan por el despliegue o por WP-CLI. Acuérdalo con el cliente antes de que note que falta el botón de actualizar.
Claves de autenticación: generadas aleatoriamente en cada instalación. Una copia de producción en staging recibe su propio juego, y las claves de producción no se tocan, porque cambiarlas cierra la sesión de todos los usuarios.

Después de mover el archivo, ejecuta wp core verify-checksums y wp plugin verify-checksums --all de la sección de pruebas antes del lanzamiento.