Configuración segura de tu web: guía 2026

Si has llegado hasta aquí es porque quieres dejar tu web bien configurada de una vez, o porque alguien te ha dicho que «no está segura» y no sabes ni por dónde empezar a mirar. Esta guía es el recorrido completo, en el orden en que hay que hacerlo: dónde vive tu web, las copias de seguridad, el certificado, el correo del dominio, los accesos, WordPress, las cabeceras, el DNS y los registros.

Te lo adelanto para que no pierdas el tiempo: más de la mitad de lo que hay aquí es gratis y te lo puedes hacer tú en una tarde. Los pasos 1, 2 y 5 son los que más riesgo quitan y no requieren ser técnico. Los pasos 7 y 8 son los que más gente se salta y donde conviene ir con calma. Cada paso lleva las rutas de fichero reales y los nombres de menú tal y como aparecen en WordPress y en el panel del hosting.

Qué depende de ti y qué depende de tu proveedor

La mayoría de los agujeros que nos encontramos no vienen de que alguien hiciera algo mal, sino de que todo el mundo pensaba que lo hacía otro: el hosting creía que la agencia actualizaba, la agencia creía que el hosting hacía copias y el dueño creía que estaba cubierto porque paga una cuota.

El reparto real de responsabilidades con el hosting

El hosting responde del hierro y de lo que hay por debajo: el servidor, la red, la versión de PHP que te ofrece, el cortafuegos perimetral y, si lo tienes contratado, las copias del propio servidor. Lo que hay dentro de tu carpeta public_html es tuyo: WordPress, el tema, los plugins, las contraseñas y el contenido.

La consecuencia práctica conviene saberla antes de que pase: si te entran por un plugin sin actualizar, tu hosting no te va a limpiar la web. Lo que hará, si el malware empieza a enviar spam o a alojar páginas de phishing, es suspenderte la cuenta para proteger al resto del servidor.

El reparto real con la agencia que te lleva la web

Con la agencia pasa parecido, con el agravante de que casi nunca está por escrito. «Mantenimiento web» puede significar desde actualizar plugins cada mes y probar la restauración de las copias, hasta renovar el hosting y cambiarte un texto cuando lo pides.

Pregúntalo sin rodeos: quién actualiza, con qué frecuencia, quién restaura si algo se rompe y quién paga las horas si hay que limpiar la web. Si la respuesta te deja mal cuerpo, revisa las cláusulas de seguridad que deberían estar en tu contrato de mantenimiento. Y ten presente que, a efectos de protección de datos, tanto el hosting como la agencia son encargados del tratamiento: quien responde ante la Agencia Española de Protección de Datos por los datos de tus clientes eres tú.

Paso 1. Elegir bien dónde vive tu web

Compartido, VPS o gestionado según lo que factures

El criterio no es el tamaño de la web, es cuánto te duele que esté caída un día entero. Si tu web es un folleto y los clientes te llegan por otro canal, un compartido decente sobra. Si la web es el canal de ventas o tienes tienda, lo que pagas de más por un alojamiento gestionado se recupera con la primera incidencia que no tienes.

Del compartido hay un detalle que casi nadie pregunta: si cada cuenta del servidor corre con su propio usuario del sistema. En servidores mal configurados, un vecino infectado puede llegar a leer tu wp-config.php, y ahí están las credenciales de tu base de datos. Pregunta si usan aislamiento por usuario (suEXEC, PHP-FPM por cuenta o CageFS). Si no saben qué les estás preguntando, ya tienes una respuesta.

Las preguntas que hay que hacer antes de pagar

¿Qué versiones de PHP ofrecéis y quién decide cuándo se cambia la mía?
¿Las copias de seguridad están incluidas o se cobran? ¿Y la restauración?
¿Cuántos días de copias guardáis y dónde, en el mismo servidor o fuera?
¿Puedo descargarme yo una copia completa cuando quiera?
¿Hay acceso SSH y SFTP? ¿El FTP sin cifrar está desactivado?
¿Qué horario real tiene el soporte y en qué idioma?
¿Qué hacéis si detectáis malware en mi cuenta: me avisáis, me suspendéis, me lo limpiáis?
¿Cuál es el precio de renovación, no el de alta, y qué me cobráis si me voy?

Están desarrolladas, con la letra pequeña de cada una, en la guía de cómo elegir hosting para tu empresa sin que te den gato por liebre.

Paso 2. Copias de seguridad que de verdad te salvan

Si solo vas a hacer una cosa de toda esta guía, haz esta: la copia de seguridad (backup) es lo que convierte un desastre en un mal rato.

Qué debe incluir una copia completa

Una copia que sirve tiene cuatro cosas: todos los ficheros (la raíz entera, no solo wp-content), la base de datos completa, la configuración que muchas herramientas excluyen por defecto (wp-config.php y .htaccess) y lo que no vive en el servidor: los registros DNS, la configuración del correo y las licencias de temas y plugins de pago.

La frecuencia depende de lo que cambies: una web corporativa que se toca una vez al mes va servida con copia semanal; un blog activo, diaria; una tienda o un sistema de reservas, diaria como mínimo, porque cada hora perdida son pedidos que hay que reconstruir a mano.

Y la retención: siete días es la configuración típica de los hostings y se queda corta. Una puerta trasera puede estar dentro semanas antes de que se note nada; si el problema empezó hace diez días, todas tus copias están ya infectadas. Guarda al menos treinta días, y una copia mensual suelta.

Por qué una copia sin restauración de prueba no es una copia

Una copia que nunca has restaurado es una carpeta pesada que da tranquilidad falsa. Haz la prueba una vez al año: monta la copia en un subdominio de pruebas (pruebas.tudominio.es), levántala entera y cronometra cuánto tardas. Ese número es el tiempo real que estarías caído.

Señales de que tu copia no vale: está en el mismo servidor que la web, es solo de ficheros o solo de base de datos, la hace un plugin que lleva meses fallando en silencio, o pesa sospechosamente poco. Lo tienes desarrollado en qué debe incluir una copia de seguridad y cada cuánto hacerla.

Paso 3. HTTPS y certificados sin sustos

Qué certificado necesitas y qué errores dan la cara en el navegador

Para una web corporativa o una tienda, un certificado gratuito de Let’s Encrypt es suficiente. Que no te vendan uno de pago diciendo que «da más confianza»: el visitante ve el mismo candado. Lo que sí falla, y mucho, es la instalación. Los tres casos de siempre:

El certificado no cubre el dominio que estás usando. El navegador muestra un aviso de nombre no válido. Casi siempre es que se emitió para tudominio.es pero la gente entra por www.tudominio.es, o al revés. Solución: emitirlo para las dos variantes.
Contenido mixto. La página va por HTTPS pero carga imágenes, tipografías o scripts por HTTP, y Chrome deja de poner el candado. Se arregla cambiando las URLs guardadas en la base de datos, no editando páginas a mano: con el plugin Better Search Replace, o por línea de comandos con wp search-replace "http://tudominio.es" "https://tudominio.es" --dry-run para ver primero cuántas coincidencias hay.
Falta la redirección. El certificado está bien pero la versión HTTP sigue viva. Compruébalo con curl -sI http://tudominio.es: debe responder un 301 hacia https://. Revisa además en Ajustes > Generales que «Dirección de WordPress» y «Dirección del sitio» estén las dos con https://.

Si tu web ya te está saliendo marcada en el navegador, empieza por el diagnóstico del aviso «No es seguro» de Chrome, que distingue el problema de certificado del de contenido mixto.

Paso 4. El correo del dominio: SPF, DKIM y DMARC

Esta es la parte que más dinero le cuesta a las pymes españolas y la que menos se toca, porque parece que «el correo funciona».

Por qué hoy cualquiera puede escribir en nombre de tu empresa

El protocolo con el que viaja el correo no comprueba quién dice ser el remitente. Sin configuración adicional, cualquiera puede enviar un mensaje que ponga tu dirección en el «De:» y llegar a la bandeja de entrada de tu cliente. De ahí salen los fraudes de cambio de número de cuenta en una factura.

Las tres piezas que lo arreglan:

SPF: un registro TXT que lista qué servidores pueden enviar en tu nombre. Tienen que estar todos: el correo de la empresa, el hosting desde el que salen los avisos de la web, la herramienta de newsletter y el CRM. Dejarse uno es el fallo más habitual.
DKIM: una firma que pone tu proveedor de correo en cada mensaje. Se activa en su panel y te da un registro que publicas en el DNS.
DMARC: le dice al servidor que recibe qué hacer cuando SPF y DKIM no cuadran, y te manda informes de quién envía en tu nombre.

Míralo tú mismo desde la consola de Windows: nslookup -type=TXT tudominio.es para el SPF y nslookup -type=TXT _dmarc.tudominio.es para el DMARC. Si el segundo no devuelve nada, no tienes DMARC.

La regla de oro: no empieces por p=reject. Publica primero v=DMARC1; p=none; rua=mailto:[email protected], deja pasar unas semanas leyendo los informes y sube la política cuando veas que todo tu envío legítimo pasa. El paso a paso está en la guía para activar DMARC sin quedarte sin correo. Y si lo que te pasa hoy es que tus mensajes acaban en la carpeta de no deseados, empieza por el diagnóstico de por qué tus correos van a spam: desde 2024 tanto Google como Microsoft exigen autenticación para aceptar volumen.

Si ya te ha pasado que alguien ha escrito a un cliente haciéndose pasar por ti, eso tiene un procedimiento propio y urgente: qué hacer cuando han suplantado el correo de tu empresa.

Paso 5. Accesos: contraseñas, verificación en dos pasos y roles

Casi ningún ataque a una pyme es sofisticado. Lo normal es una contraseña reutilizada que apareció en la filtración de otro servicio, o un ordenador con un troyano que se llevó las claves guardadas en el navegador. Tres cosas, por orden de importancia:

Verificación en dos pasos donde de verdad duele. El primero de la lista no es WordPress: es el registrador de tu dominio. Si lo pierdes, pierdes web y correo a la vez. Después: panel del hosting, correo, WordPress y pasarela de pago.
Contraseñas únicas y largas, en un gestor. No hace falta memorizarlas ni cambiarlas cada tres meses; hace falta que no se repitan.
Roles bien puestos. En Usuarios > Todos los usuarios, mira cuántos administradores hay. El que solo escribe entradas es Autor, y el diseñador que terminó hace un año no debería seguir ahí.

Cuando cambies contraseñas por una sospecha, cambia también las claves de seguridad de wp-config.php: genera unas nuevas en https://api.wordpress.org/secret-key/1.1/salt/ y sustituye el bloque define('AUTH_KEY', ...). Eso cierra de golpe todas las sesiones abiertas, incluida la del que se hubiera colado.

Paso 6. Endurecer WordPress: wp-login, XML-RPC y actualizaciones

Cuatro medidas concretas que rinden mucho y no rompen casi nada:

Limitar intentos de acceso. Los ataques contra /wp-login.php son automáticos y constantes; no hay nadie tecleando. Limitar intentos por IP es lo que más rinde por menos esfuerzo, y lo tienes en cualquier plugin de seguridad o en el panel del hosting. Qué funciona y qué es puro teatro, en cómo proteger wp-login.php de la fuerza bruta.
XML-RPC. Si no usas la aplicación móvil de WordPress, ni Jetpack, ni publicas desde herramientas externas, desactívalo: es una puerta paralela al mismo panel. Compruébalo antes, porque algunos plugins lo usan por dentro.
Prohibir el editor de ficheros del panel. Añade en wp-config.php la línea define('DISALLOW_FILE_EDIT', true);. A quien entre con una cuenta de administrador le quitas la vía más cómoda para subir código.
Bloquear la ejecución de PHP en wp-content/uploads/. Ahí solo debería haber imágenes y documentos. Crea un .htaccess dentro que deniegue el acceso a los ficheros .php: eso convierte una subida maliciosa en un fichero inerte.

Sobre actualizaciones: activa las automáticas para las versiones menores del núcleo y hazlo tú, con cabeza, para plugins y tema. En Herramientas > Salud del sitio tienes además el aviso de si tu PHP está fuera de soporte. Antes conviene saber qué tienes instalado de verdad, incluidos los plugins que vinieron dentro del tema: cómo listar los plugins de tu WordPress y ver cuáles sobran. Después, cómo actualizar los plugins sin romper la web y el panorama completo de vulnerabilidades en plugins de WordPress.

Paso 7. Cabeceras de seguridad HTTP, una por una

Las cabeceras son instrucciones que tu servidor manda al navegador junto con la página. No arreglan un plugin vulnerable, pero limitan el daño de varios ataques y son gratis. Para ver las que tienes: abre tu web en Chrome, pulsa F12, pestaña Red, recarga, haz clic en la primera petición (la del documento) y mira Encabezados de respuesta. O por consola: curl -sI https://tudominio.es. Las que hoy merecen la pena:

Strict-Transport-Security: obliga al navegador a usar siempre HTTPS. Actívala solo cuando tengas el certificado bien y todo el sitio en HTTPS; si la pones antes, dejas la web inaccesible durante el tiempo que dure la cabecera.
Content-Security-Policy: la más potente y la más delicada. Empieza en modo informe (Content-Security-Policy-Report-Only) o solo con la directiva frame-ancestors, que evita que te metan dentro de un iframe.
X-Content-Type-Options: nosniff: una línea, sin efectos secundarios, ponla.
Referrer-Policy: strict-origin-when-cross-origin: evita filtrar la URL completa a terceros.
Permissions-Policy: desactiva cámara, micrófono y geolocalización si tu web no los usa.

Se configuran en .htaccess si tu servidor es Apache, en la configuración del sitio si es nginx, en las reglas de Cloudflare o con un plugin. Un aviso: copiar la política de contenido de otra web es la forma más rápida de quedarte sin formularios ni analítica, porque cada web carga recursos distintos. Si solo vas a poner una, pon nosniff; si vas a hacerlo bien, sigue el desglose de qué cabeceras de seguridad importan hoy.

Paso 8. DNS, CDN y WAF: la capa de delante

El DNS es la centralita de tu dominio y casi nadie lo mira hasta que falla. Dos medidas: verificación en dos pasos en el registrador y, si te lo ofrece, bloqueo de transferencia del dominio. Revisa también los registros publicados: es habitual encontrar entradas de servicios que se dejaron de usar hace años, y esos apuntes olvidados dan problemas si el servicio al que apuntan cambia de dueño.

Sobre el WAF (el cortafuegos de aplicación, el de Cloudflare o el que incluya tu hosting): filtra muchísimo ruido automático y está bien tenerlo, pero seamos honestos, no arregla un plugin vulnerable, solo hace más ruidoso explotarlo. Y tiene una trampa clásica: si pones un CDN delante pero la IP real de tu servidor sigue siendo accesible, el atacante va directo al origen y se salta toda la capa. Si montas CDN, pide a tu hosting que limite las conexiones al origen a las IP del proveedor.

Paso 9. Logs y vigilancia: enterarte antes que tu cliente

La diferencia entre un susto y una crisis suele ser cuánto tardas en enterarte, y la peor forma de descubrir que tu web está comprometida es que te llame un cliente. Dónde están tus registros: en cPanel, Métricas > Registros sin procesar tiene los accesos y Errores los fallos de PHP; en muchas instalaciones hay además un fichero error_log en la raíz de public_html. Lo que hay que buscar:

Ráfagas de peticiones POST a /wp-login.php o a /xmlrpc.php desde pocas IP.
Peticiones a ficheros .php dentro de /wp-content/uploads/: ahí no debería ejecutarse nada, y si alguien lo pide es que sabe que hay algo.
Muchos 404 seguidos contra rutas de plugins que ni siquiera tienes: es un escaneo buscando cuál llevas.
Accesos correctos a horas raras o desde países donde no tienes a nadie.

Conviene vigilar además tres cosas de forma continua: que la web responde, que los ficheros del núcleo no cambian solos y que el dominio no aparece en listas de reputación. Revisarlo a mano una vez al mes ya te pone por delante de la mayoría. Si encuentras señales claras, no toques nada todavía y lee primero la guía de qué hacer con una web hackeada: borrar antes de mirar destruye las pruebas que vas a necesitar después.

Paso 10. WooCommerce: qué cambia cuando cobras online

En cuanto vendes cambian dos cosas: manejas datos personales de verdad y hay dinero en juego, así que el interés del atacante deja de ser genérico.

No guardes datos de tarjeta. Nunca, en ningún campo. Usa la pasarela (Stripe, Redsys, PayPal) para que los datos no pasen por tu servidor.
Revisa las claves de API y los webhooks, en WooCommerce > Ajustes > Avanzado > API REST y en Webhooks. Ahí se acumulan permisos de integraciones antiguas, y ahí deja un atacante los suyos porque nadie mira.
Vigila el rol Gestor de tienda, que da acceso a pedidos y clientes; no es para repartirlo alegremente.
Prueba un pedido completo después de cada actualización, con un cupón del 100% si hace falta, pero de principio a fin.
Sube la frecuencia de copias: perder un día de pedidos no se arregla restaurando.

Para saber si tu instalación está al día y qué revisar en extensiones, tienes el detalle en cómo comprobar si tu WooCommerce es vulnerable. Y en el plano legal, un comercio electrónico es justo el caso en el que la Agencia mira con lupa qué medidas de seguridad apropiadas habías implantado antes del incidente.

Si la web la lleva otro: qué exigir y cómo auditar lo entregado

Que no la lleves tú no te quita la responsabilidad. Lo que sí puedes hacer es comprobar, sin ser técnico, si lo entregado está realmente terminado:

Pide la lista de usuarios con acceso y quita a quien ya no trabaje contigo.
Pide una copia completa descargable y quédatela tú. Es tu web.
Comprueba que el dominio está a nombre de tu empresa, no de la agencia.
Pide las licencias de tema y plugins de pago a tu nombre. Si no las hay, pregunta de dónde salieron: un plugin de una web de «nulled» suele traer regalo dentro.
Pide por escrito la frecuencia de actualizaciones y de copias.

El listado completo está en cómo auditar la web que te ha entregado una agencia.

Checklist final y en qué orden hacerlo

Estos 30 días (lo barato y lo que más riesgo quita):

Verificación en dos pasos en registrador, hosting, correo y WordPress.
Revisar y limpiar la lista de administradores.
Comprobar que hay copias con ficheros y base de datos, y descargarte una.
Actualizar núcleo, plugins y tema, de uno en uno.
Comprobar que el HTTPS está bien y que HTTP redirige.
Publicar SPF y DMARC en p=none.

Estos 90 días (lo que requiere una tarde tranquila):

Restaurar una copia en un subdominio de pruebas y cronometrarlo.
Limitar intentos de acceso y decidir qué hacer con XML-RPC.
Bloquear la ejecución de PHP en uploads y añadir DISALLOW_FILE_EDIT.
Poner las cabeceras fáciles y empezar la política de contenido en modo informe.
Subir DMARC a quarantine si los informes acompañan.
Leer los registros de acceso una vez, para saber cómo se ve lo normal.

Este año: dejar por escrito con tu proveedor quién actualiza, quién restaura y en cuánto tiempo; poner DMARC en reject; revisar si el alojamiento sigue encajando con lo que factura la web; y repetir la prueba de restauración y la revisión de roles.

Preguntas frecuentes

¿Con un plugin de seguridad no me vale?

Ayuda, sobre todo para limitar intentos de acceso y avisarte de cambios en ficheros. Pero no sustituye a las copias, ni a actualizar, ni a la configuración del correo, ni a tener bien los accesos, y tampoco limpia una web ya infectada. Comparativa sin humo en cuál es el mejor plugin de seguridad para WordPress.

¿Cuánto cuesta todo esto?

Con honestidad: los pasos 2, 3, 4, 5, 6 y 7 no cuestan dinero, cuestan tiempo. Lo único que puede subirte la factura es cambiar a un alojamiento mejor. Donde sí se paga es cuando ya ha pasado algo: limpiar una web comprometida ronda los 500 euros y una vigilancia continua con mantenimiento está en el entorno de 69 euros al mes. Y hay ayudas públicas que cubren parte de esto: mira si te encaja lo que cubre de verdad el Kit Digital en ciberseguridad.

¿Necesito ser técnico?

Para los pasos 1, 2, 5 y 10, no. Para el 6 y el 7 necesitas perder el miedo a tocar dos ficheros, con una copia hecha antes. El paso 8 y la lectura fina de registros son los que más se atragantan: si te ves editando configuración del servidor sin saber qué cambias, para y pide ayuda. Sale más barata una hora de alguien que un día de web caída.

¿Y si creo que ya estoy comprometido?

Entonces esta guía no es tu prioridad de hoy. Contén sin destruir pruebas y mira si hay datos personales de por medio, porque en ese caso corre un plazo legal: cómo notificar una brecha a la AEPD en 72 horas y qué obligaciones legales tienes cuando te atacan la web. Cuando esté limpia, vuelve aquí: la reinfección casi siempre entra por donde entró la primera vez.

Antes de ponerte con nada, merece la pena mirar tu web desde fuera, que es justo lo que ve un atacante cuando la escanea: certificado, cabeceras, versiones expuestas y señales de compromiso. Analiza tu web gratis con PathScan: sin registro, sin tocar tu servidor, y en un minuto sabrás por cuál de los diez pasos te toca empezar.

Seguir leyendo en esta sección

Ver todo en Endurecer tu web → · Mapa completo del sitio