¿Cómo limpiar un sitio WordPress hackeado? Guía práctica de eliminación de malware (2026)

Descubre más sobre servicios de auditoría de seguridad WordPress en WPPoland. Si prefieres delegar la limpieza, la página eliminar malware de WordPress explica cómo lo hago.

Esta guía recorre paso a paso el proceso de limpieza de un WordPress infectado. Usa herramientas de línea de comandos (SSH, WP-CLI) porque son más rápidas y completas que cualquier plugin; los escáneres en forma de plugin aparecen más abajo, en la sección sobre la documentación de WordPress.org.

#Signos de que tu WordPress está hackeado

Antes de empezar a limpiar, confirma que tu sitio realmente está comprometido. Los signos más comunes incluyen:

• Redirecciones no deseadas: Los visitantes son redirigidos a sitios de spam, farmacia o casinos
• Contenido spam inyectado: Páginas con texto en japonés, chino o enlaces a sitios maliciosos
• Usuarios administradores desconocidos: Nuevas cuentas de administrador que tú no creaste
• Archivos modificados recientemente: Archivos del core, temas o plugins cambiados sin tu conocimiento
• Advertencias de Google: una etiqueta de aviso en los resultados de búsqueda o una página intersticial de advertencia en el navegador
• Caída de tráfico SEO: Google ha penalizado o desindexado tu sitio
• Correos spam enviados: Tu servidor está enviando correos no deseados
• Rendimiento degradado: El sitio se ha vuelto notablemente más lento

Si la primera señal fueron páginas japonesas en Google y no algo visible en el sitio, probablemente tengas la variante encubierta, que exige un primer paso distinto: consulta el hackeo de palabras clave japonesas antes de borrar nada.

#Cómo entran los atacantes en un sitio WordPress

Los bots maliciosos rastrean la web en busca de vulnerabilidades conocidas, prueban credenciales de administrador por fuerza bruta y explotan servidores mal configurados. Para limpiar un sitio, primero hay que entender cómo consiguió acceso el atacante.

#Vulnerabilidades en plugins y temas desactualizados

Vulnerabilidades como inyección SQL (SQLi), inclusión local de archivos (LFI) y ejecución remota de código (RCE) aparecen con frecuencia en plugins desactualizados. Los atacantes usan herramientas automáticas para detectar versiones vulnerables conocidas y ejecutar sus cargas. Dos clases de vulnerabilidad son especialmente peligrosas:

• Inyección de objetos PHP (deserialización): ocurre cuando una entrada del usuario llega directamente a la función unserialize() de PHP. Si el código contiene clases auxiliares que sirven como “POP chain”, el atacante puede instanciar objetos PHP arbitrarios, ejecutar código y escribir archivos en el sistema.
• Subida de archivos sin restricciones: si un plugin no valida bien los archivos enviados desde formularios propios (por ejemplo, comprueba la extensión solo en el navegador y no en el servidor), el atacante puede subir una web shell disfrazada de imagen, guardarla en /wp-content/uploads/ y ejecutarla con una petición HTTP directa.

#Credenciales débiles y ataques de fuerza bruta

Los bots golpean sin pausa /wp-login.php y /xmlrpc.php con listas de contraseñas comunes. Si la cuenta de administrador usa una contraseña débil, acabará comprometida.

#Cómo abusan los atacantes de xmlrpc.php

El archivo heredado xmlrpc.php permite interactuar con la API de WordPress mediante XML. Como admite peticiones multicall, un atacante puede probar cientos de combinaciones de credenciales en una sola petición HTTP y saltarse los límites normales de inicio de sesión.

#Infección desde otros sitios en hosting compartido

Si tu sitio está en un servidor compartido, una vulnerabilidad en el sitio de un vecino puede permitir al atacante escribir archivos en el árbol de directorios e infectar tus archivos limpios.

#Qué recomienda WordPress.org hacer primero cuando un sitio ha sido hackeado

El artículo de soporte de WordPress.org FAQ My site was hacked trata la primera hora como trabajo de documentación, no de limpieza. Su primer paso concreto es anotar lo que ves, cuándo lo notaste (con la zona horaria) y qué cambió recientemente: un plugin nuevo, una edición del tema, un cambio en un widget. Esa nota es la base del informe del incidente, tanto si limpias el sitio tú mismo como si lo entregas a otra persona.

El mismo artículo enumera indicadores de compromiso que apuntan a un hackeo real y no a una caída: el sitio está en una lista negra de Google o Bing, el hosting lo ha desactivado, está marcado por distribuir malware, el antivirus de los visitantes lo bloquea, alguien informa de que ataca a otros sitios o aparecen usuarios que nadie creó.

Para la exploración, el artículo combina escáneres a nivel de aplicación (los plugins Wordfence, Sucuri, Quttera y GOTMLS) con escáneres remotos como VirusTotal y Sucuri SiteCheck, porque cada tipo informa de cosas distintas.

Cuatro puntos de ese artículo se olvidan fácilmente bajo presión:

• Analiza también tu propio ordenador. El artículo señala que muchas infecciones empiezan en el equipo del propietario, donde un troyano captura las credenciales de FTP y de wp-admin. Las contraseñas nuevas escritas en un portátil infectado llegan directamente al atacante.
• Habla pronto con el hosting. En un hosting compartido el hackeo puede afectar a más de un sitio, y un sitio usado para enviar spam puede llevar la IP del servidor a listas negras de correo, lo que afecta al correo enviado desde ese mismo servidor.
• Reinstala la misma versión, y no desde wp-admin. El artículo desaconseja las opciones de reinstalación del escritorio porque esos instaladores a menudo solo sobrescriben archivos existentes, mientras que los hackeos añaden archivos nuevos. Menciona /wp-admin y /wp-includes como los directorios que se pueden reemplazar con seguridad.
• Cambia las contraseñas dos veces. Una al descubrir el hackeo y otra cuando el sitio esté confirmado como limpio, en todos los puntos de acceso: SFTP, wp-admin, el panel del hosting y MySQL. El artículo también sugiere cambiar el usuario y la contraseña de la base de datos y actualizar wp-config.php en consecuencia.

También nombra los archivos que merecen una revisión manual sea cual sea el tipo de infección, porque un cambio en ellos afecta a todas las peticiones: .htaccess (en la raíz y en cualquier subdirectorio que lo tenga), index.php y los archivos del tema header.php, footer.php y functions.php.

#Cómo desconectar un WordPress hackeado durante la limpieza

La guía de Google Quarantine your site recomienda desconectar el sitio hackeado para que deje de servir contenido a los usuarios y responder con el código 503, que indica una caída temporal. Para WordPress importan dos detalles:

• Sirve el 503 desde fuera del árbol comprometido, por ejemplo desde la configuración del servidor web o del proxy que controla el hosting. Un plugin de mantenimiento o un archivo PHP dentro de la instalación infectada se ejecuta junto al malware.
• Una respuesta 4xx o 5xx por sí sola no basta, porque “con estos códigos de estado todavía se puede devolver contenido dañino a los usuarios” (Google, Quarantine your site, traducción propia). Un disallow en robots.txt tampoco basta: solo bloquea a los rastreadores de los buscadores, no a los visitantes.

La guía afirma que desconectar el sitio de forma temporal durante la recuperación difícilmente afectará al posicionamiento futuro. Sus otros dos pasos coinciden con WordPress.org: avisar al hosting, revisar la lista de usuarios, borrar las cuentas creadas por el atacante y cambiar todas las contraseñas (FTP, base de datos, administrador del sistema y CMS).

Vuelve a poner el sitio en línea antes de pedir la revisión a Google, porque la revisión necesita páginas que Googlebot pueda rastrear.

#Cómo hacer backup de un WordPress hackeado

Antes de hacer cualquier cambio, crea un backup completo del estado infectado. Esto es crucial por dos razones: (1) si algo sale mal durante la limpieza, puedes restaurar, y (2) puedes analizar el malware después para entender cómo ocurrió la brecha.

# Crear backup completo de archivos
tar -czf /tmp/backup-infectado-$(date +%Y%m%d).tar.gz /var/www/html/

# Exportar base de datos
wp db export /tmp/backup-db-infectado-$(date +%Y%m%d).sql --path=/var/www/html/

#Cómo revisar los logs de acceso de WordPress por SSH

Para localizar el punto de entrada y el momento del hackeo, revisa los logs de acceso del servidor web con comandos SSH. Así encontrarás peticiones POST maliciosas que coinciden con las fechas de modificación de los archivos.

# IP con muchas peticiones POST al login o a XML-RPC
grep -h "POST /wp-login.php" /var/log/nginx/access.log* | awk '{print $1}' | sort | uniq -c | sort -nr | head -n 20
grep -h "POST /xmlrpc.php" /var/log/nginx/access.log* | awk '{print $1}' | sort | uniq -c | sort -nr | head -n 20

# Intentos de explotación contra rutas conocidas
grep -E "wp-config\.php|\.env|eval\(|union\+select" /var/log/nginx/access.log

# Peticiones de una IP que modificó archivos durante la ventana del ataque
grep "192.168.1.100" /var/log/nginx/access.log | grep -E "POST|PUT"

Identificar la IP de origen y el script exacto que procesó la petición revela el plugin o tema explotado, y así puedes corregir la vulnerabilidad.

#Cómo encontrar malware en un WordPress hackeado

#Cómo encontrar archivos PHP sospechosos

Usa grep para buscar patrones comunes de malware en tus archivos:

# Buscar funciones de ofuscacion comunes
grep -rn "eval(" /var/www/html/wp-content/ --include="*.php"
grep -rn "base64_decode" /var/www/html/wp-content/ --include="*.php"
grep -rn "str_rot13" /var/www/html/wp-content/ --include="*.php"
grep -rn "gzinflate" /var/www/html/wp-content/ --include="*.php"

# Buscar archivos PHP en uploads (NO deberia haber ninguno)
find /var/www/html/wp-content/uploads/ -name "*.php" -type f

# Buscar archivos modificados en los ultimos 7 dias
find /var/www/html/ -name "*.php" -mtime -7 -type f

#Cómo revisar los administradores en la base de datos

-- Buscar administradores sospechosos
SELECT ID, user_login, user_email, user_registered
FROM wp_users
WHERE ID IN (
    SELECT user_id FROM wp_usermeta
    WHERE meta_key = 'wp_capabilities'
    AND meta_value LIKE '%administrator%'
);

#Tipos de hackeo de WordPress más comunes en 2026

#Cómo reemplazar el core de WordPress tras un hackeo

El método más seguro es reemplazar todos los archivos del core con versiones limpias:

# Descargar core limpio sin tocar wp-content
wp core download --force --skip-content --path=/var/www/html/

# Verificar la integridad
wp core verify-checksums --path=/var/www/html/

Esto reemplaza wp-admin/, wp-includes/ y todos los archivos del core raíz con versiones originales, eliminando las modificaciones maliciosas de esos archivos.

#Cómo interpretar wp core verify-checksums y la verificación de plugins

wp core verify-checksums descarga de WordPress.org las sumas md5 de la versión instalada y las compara con los archivos del disco. Según la referencia del comando, lo hace sin cargar WordPress, algo importante en un sitio donde cargar WordPress ejecuta el malware.

Un core limpio termina con Success: WordPress installation verifies against checksums. Cada archivo modificado genera una línea como Warning: File doesn't verify against checksum: wp-includes/version.php, y la ejecución acaba con Error: WordPress installation doesn't verify against checksums.

Opciones útiles después de un hackeo:

• --include-root revisa también el directorio raíz y avisa si encuentra elementos que no pertenecen a WordPress, que es donde aparecen los cargadores dejados junto a wp-load.php.
• --version=<version> y --locale=<locale> comparan con una versión y un idioma concretos.
• --format=json devuelve una salida legible por máquina para un script o un ticket del incidente.
• --insecure reintenta la descarga sin validar el certificado. La referencia advierte que eso deja la petición expuesta a un ataque de intermediario, así que no lo uses en un servidor comprometido.

wp core download --force solo sobrescribe los archivos existentes, según la referencia de la descarga. Los archivos que el atacante añadió dentro de wp-admin/ o wp-includes/ pueden sobrevivir. El orden más seguro es borrar esos dos directorios, que la FAQ de WordPress.org considera seguros de reemplazar, y después descargar y verificar.

Para los plugins, wp plugin verify-checksums --all comprueba sus archivos con las sumas de WordPress.org, y --strict hace fallar incluso los “cambios menores”, como las ediciones de readme.txt (referencia). Como las sumas vienen de WordPress.org, el comando cubre los plugins del directorio de WordPress.org. Los plugins premium y propios necesitan un paquete nuevo del proveedor o de tu propio repositorio.

wp core verify-checksums --include-root --path=/var/www/html
wp plugin verify-checksums --all --strict --path=/var/www/html

#Cómo limpiar wp-content en un WordPress infectado

#Cómo reinstalar los plugins tras un hackeo

La forma más segura es eliminar y reinstalar todos los plugins:

# Listar plugins activos
wp plugin list --status=active --path=/var/www/html/

# Reinstalar cada plugin desde el repositorio
wp plugin install nombre-del-plugin --force --path=/var/www/html/

Para plugins premium, descarga versiones frescas del proveedor original.

#Qué hacer con los temas tras un hackeo

Elimina todos los temas excepto el activo. Para el tema activo, compara archivos con la versión original línea por línea.

#Cómo eliminar archivos PHP de la carpeta uploads

La carpeta uploads NUNCA debería contener archivos PHP. Elimina cualquiera que encuentres:

find /var/www/html/wp-content/uploads/ -name "*.php" -delete
find /var/www/html/wp-content/uploads/ -name "*.phtml" -delete
# Solo listar y revisar .htaccess, no borrarlo: WooCommerce protege woocommerce_uploads/ con su propio .htaccess
find /var/www/html/wp-content/uploads/ -name ".htaccess"

#Cómo limpiar la base de datos de un WordPress hackeado

#Cómo eliminar administradores falsos

-- Eliminar usuarios sospechosos (verifica IDs primero)
DELETE FROM wp_users WHERE ID IN (lista_de_ids_sospechosos);
DELETE FROM wp_usermeta WHERE user_id IN (lista_de_ids_sospechosos);

#Cómo encontrar scripts inyectados en wp_posts y wp_options

-- Buscar scripts inyectados en posts
SELECT ID, post_title
FROM wp_posts
WHERE post_content LIKE '%<script%'
OR post_content LIKE '%eval(%';

-- Buscar opciones sospechosas
SELECT option_name, option_value
FROM wp_options
WHERE option_name LIKE '%hack%'
OR option_name LIKE '%inject%'
OR option_value LIKE '%base64_decode%';

#Cómo eliminar puertas traseras en el cron y en la configuración de WordPress

El malware suele programar tareas cron que vuelven a infectar los archivos limpios. Por eso, aunque reemplaces todos los archivos del sistema, el sitio puede volver a infectarse en pocas horas.

#Cómo revisar las tareas cron de WordPress

Todas las tareas programadas se guardan como arrays serializados en la tabla wp_options, en la opción cron. Con este comando de WP-CLI ves los eventos programados:

# Listar todos los eventos cron programados
wp cron event list --path=/var/www/html

#Cómo borrar un evento cron malicioso con PHP

Si encuentras un hook de cron desconocido (por ejemplo, wp_update_system_cache apuntando a código dinámico), este script PHP lo elimina:

declare(strict_types=1);

namespace WPPoland\Security\Cron;

/**
 * Elimina hooks de cron maliciosos de la programación.
 */
function remove_malicious_cron_event(): void {
    $target_hook = 'wp_update_system_cache';

    // Quitar el hook si está programado
    $timestamp = wp_next_scheduled( $target_hook );
    if ( $timestamp ) {
        wp_unschedule_event( $timestamp, $target_hook );
        error_log( sprintf( 'Security Action: Unscheduled backdoor hook "%s".', $target_hook ) );
    }
}
add_action( 'init', __NAMESPACE__ . '\\remove_malicious_cron_event' );

#Cómo encontrar puertas traseras en .user.ini y .htaccess

Un mecanismo de persistencia habitual es inyectar archivos .user.ini o .htaccess en la raíz del sitio. El atacante define directivas de PHP como auto_prepend_file para ejecutar un script malicioso antes de que cargue cualquier código de WordPress:

; Puerta trasera maliciosa en .user.ini
auto_prepend_file = "/var/www/html/wp-content/uploads/2026/06/backdoor.jpg"

Como este archivo actúa de forma global, cualquier petición PHP, incluida la pantalla de acceso, ejecuta la puerta trasera. Busca cambios en .user.ini y .htaccess en la raíz del sitio y comprueba que no se antepone ni se añade ningún script no autorizado.

#Cómo endurecer WordPress después de limpiar malware

Después de la limpieza, fortalece tu sitio contra futuros ataques:

#Cómo cambiar la contraseña de admin y las claves salt

# Cambiar contraseña de administrador
wp user update admin --user_pass="nueva-contraseña-segura" --path=/var/www/html/

# Regenerar Salt Keys (cierra todas las sesiones activas)
wp config shuffle-salts --path=/var/www/html/

#Qué protecciones añadir en wp-config.php

// Deshabilitar edición de archivos desde el admin
define('DISALLOW_FILE_EDIT', true);

// Deshabilitar instalacion de plugins/temas desde el admin
define('DISALLOW_FILE_MODS', true);

// Forzar SSL en admin
define('FORCE_SSL_ADMIN', true);

#Qué permisos de archivos usar en WordPress

# Directorios: 755
find /var/www/html/ -type d -exec chmod 755 {} \;

# Archivos: 644
find /var/www/html/ -type f -exec chmod 644 {} \;

# wp-config.php: 400 (solo lectura)
chmod 400 /var/www/html/wp-config.php

#Quién debe ser el propietario de los archivos de WordPress

Además de los permisos, revisa la propiedad de los archivos. El proceso del servidor web (por ejemplo www-data o apache) no debería ser el propietario de los archivos PHP de WordPress. Asigna como propietario a un usuario de despliegue independiente (por ejemplo wp-user) y como grupo a www-data. Así, un proceso del servidor web comprometido no puede escribir ni modificar los archivos .php del sistema:

# Propietario: usuario de despliegue; grupo: servidor web
chown -R wp-user:www-data /var/www/html/

# Escritura del servidor web solo en uploads
chown -R www-data:www-data /var/www/html/wp-content/uploads/

#Sistema de archivos de solo lectura para WordPress en Docker

La documentación oficial de la imagen (docker-library/docs) describe un despliegue estático: construir una imagen propia con el código en /usr/src/wordpress y ejecutarla en solo lectura, con almacenamiento escribible solo para /tmp, /run y, opcionalmente, wp-content/uploads. Por defecto la imagen guarda WordPress en un volumen escribible /var/www/html y se actualiza ahí, así que read_only: true sobre la imagen estándar no da esta protección.

FROM wordpress:apache
WORKDIR /usr/src/wordpress
RUN set -eux; \
	find /etc/apache2 -name '*.conf' -type f -exec sed -ri -e "s!/var/www/html!$PWD!g" -e "s!Directory /var/www/!Directory $PWD!g" '{}' +; \
	cp -s wp-config-docker.php wp-config.php
COPY custom-theme/ ./wp-content/themes/custom-theme/
COPY custom-plugin/ ./wp-content/plugins/custom-plugin/

# docker-compose.yml: imagen propia en solo lectura
services:
  wordpress:
    image: custom-wordpress:tag
    read_only: true
    tmpfs:
      - /tmp
      - /run
    volumes:
      - ./uploads:/usr/src/wordpress/wp-content/uploads

Con la capa de código sellada, un fallo que permita escribir archivos solo alcanza el volumen de uploads, por eso las comprobaciones de uploads de esta guía siguen siendo necesarias. Actualizar significa reconstruir y volver a desplegar la imagen, y la documentación recuerda hacerlo con regularidad para recibir las actualizaciones de seguridad de WordPress.

#Qué añade la guía de endurecimiento de WordPress tras una limpieza

La guía Hardening WordPress fija wp-config.php en 400 o 440, para que solo tú y el servidor web podáis leerlo. Sobre DISALLOW_FILE_EDIT dice que “no impedirá que un atacante suba archivos maliciosos a tu sitio, pero puede detener algunos ataques” (WordPress.org, Hardening WordPress, traducción propia). Para el usuario de la base de datos bastan los privilegios de lectura y escritura en el funcionamiento normal, pero la guía desaconseja retirar privilegios estructurales como ALTER, porque algunas actualizaciones y plugins cambian el esquema. Sobre la monitorización, recomienda ejecutar el control de archivos como root para que el atacante no pueda desactivarlo fácilmente, vigilar solo tipos de archivo ejecutables como .php para reducir el ruido y guardar copias periódicas, de modo que tengas versiones de antes y de después de un compromiso.

#Cómo verificar que el malware de WordPress se eliminó

#Lista de verificación tras eliminar el malware

• Core de WordPress verificado con checksums
• Todos los plugins reinstalados desde fuentes limpias
• Archivos PHP eliminados de uploads
• Usuarios administradores falsos eliminados
• Contraseñas cambiadas para todos los usuarios
• Salt Keys regeneradas
• Permisos de archivos corregidos
• DISALLOW_FILE_EDIT habilitado
• XML-RPC deshabilitado si no se necesita
• Plugin de seguridad instalado (Wordfence, Sucuri)
• Backups automáticos configurados

#Cómo informa Google de un sitio hackeado y cuánto tarda la revisión

Los hallazgos de Google aparecen en Search Console, en el informe de problemas de seguridad (Ayuda de Search Console). Las páginas afectadas pueden mostrar una etiqueta de aviso en los resultados de búsqueda o una advertencia intersticial en el navegador. El informe usa cuatro categorías de hackeo:

La misma página fija tres reglas. Corrige el problema en todo el sitio, porque arreglar solo algunas páginas no devuelve parcialmente el sitio a los resultados. Pulsa Request Review solo cuando todos los problemas del informe estén corregidos en todas las páginas. No reenvíes la solicitud mientras haya otra pendiente. Una buena solicitud explica el problema exacto, describe los pasos dados para corregirlo y documenta el resultado.

La guía de Google Request a review añade los requisitos previos: propiedad verificada en Search Console, el sitio limpio, la vulnerabilidad corregida y el sitio otra vez en línea para que Googlebot pueda rastrearlo. Comprueba antes con cURL o Wget la página de inicio y una URL que el atacante modificó. Una solicitud enviada mientras el problema persiste alarga el tiempo que el sitio sigue marcado.

Si Google considera el sitio limpio, las advertencias del navegador y de la búsqueda se retiran en un plazo de 72 horas. Si no, el informe puede mostrar más URL de ejemplo y las advertencias se mantienen. Google no es la única lista: la FAQ de WordPress.org recomienda registrar el sitio también en Bing Webmaster Tools, Yandex Webmaster y Norton Safe Web, porque los visitantes pueden usar cualquiera de ellas.

El 20 de octubre de 2026 Google anunció que Chrome divide en dos niveles los avisos de Safe Browsing sobre sitios web cuando está activada la protección mejorada: sitios sospechosos (veredicto de menor confianza, posible riesgo para el usuario) y sitios peligrosos (veredicto de alta confianza, riesgo alto para el usuario) (Google, 20 de octubre de 2026). Los peligrosos siguen mostrando la pantalla roja de aviso a página completa. El aviso de sitio sospechoso cambia de formato, icono, color y texto, y Google lo muestra cuando una página presenta patrones engañosos habituales en sitios maliciosos conocidos.

#Cómo evitar que WordPress vuelva a ser hackeado

La mejor defensa es la prevención:

• Actualiza siempre: Core, plugins y temas, automáticamente si es posible
• Usa contraseñas fuertes: Mínimo 16 caracteres, únicas para cada cuenta
• Implementa 2FA: Autenticación de dos factores para todas las cuentas admin
• Hosting seguro: VPS con firewall, no hosting compartido
• Backups diarios: Automatizados y almacenados offsite
• Monitoreo continuo: Alertas de cambios de archivos y actividad sospechosa

#Cómo es un plan de seguridad de 90 días para WordPress

• Días 1-30 (triaje inmediato): auditoría completa de integridad de archivos con WP-CLI para detectar archivos del core modificados. Rota las contraseñas de la base de datos, las credenciales root de la base de datos y las claves de acceso SSH/SFTP. Rota los salts de wp-config.php para cerrar las sesiones activas y desactiva la edición directa de temas y plugins con DISALLOW_FILE_EDIT.
• Días 31-60 (forense y cortafuegos): revisa las tareas cron activas para confirmar que no queda ninguna función maliciosa programada. Analiza los logs del servidor web en busca de comportamientos anómalos, picos de POST a XML-RPC o patrones de LFI. Implanta un cortafuegos de aplicaciones web (WAF) en el servidor o un proxy inverso (por ejemplo Cloudflare) para bloquear cargas SQLi y XSS en el borde.
• Días 61-90 (endurecimiento y auditoría): configura copias automáticas externas en un almacenamiento de tipo WORM (escritura única, lectura múltiple). Haz análisis estático de código y pruebas de penetración en temas propios y plugins a medida. Programa escaneos de seguridad trimestrales y define un protocolo de respuesta a incidentes para el equipo.

Explora nuestros servicios de auditoría de seguridad WordPress y mantenimiento WordPress para proteger tu sitio profesionalmente.