Mi WordPress sale en japonés en Google: qué es y cómo eliminarlo

Buscas el nombre de tu empresa en Google y entre tus resultados aparecen títulos en japonés, con productos que tú no vendes, colgando de tu propio dominio. Entras en la web y todo se ve normal: tu portada, tus servicios, nada raro. No es un fallo de Google ni un error de idioma: alguien ha entrado en tu WordPress y está usando tu dominio para posicionar páginas de productos falsificados. Tiene solución y el orden importa. En este artículo tienes las cuatro cosas que hay que hacer, en secuencia: medir cuántas URLs hay, borrar las páginas, encontrar el fichero que las vuelve a crear cada noche y avisar a Google.

Qué es exactamente el ataque de palabras en japonés

Se le conoce como japanese keyword hack y lleva años funcionando porque es muy rentable para quien lo monta. El atacante entra en tu WordPress —normalmente por un plugin desactualizado o una contraseña reutilizada— y en lugar de destrozarte la web, se esconde. Tu web le vale más viva que muerta.

Lo que hace es generar cientos o miles de páginas nuevas dentro de tu dominio, con títulos y textos en japonés, que venden réplicas de marcas de lujo, zapatillas o relojes. Esas páginas aprovechan la reputación que tu dominio ya tiene ante Google. Cuanto más antiguo y mejor posicionado sea tu sitio, más valor tiene para el atacante.

Casi siempre viene acompañado de dos cosas más: un usuario administrador que tú no has creado y un fichero puerta trasera que le permite volver a entrar aunque cambies la contraseña. Por eso borrar las páginas y quedarse tranquilo no funciona. Si quieres el contexto completo de qué le está pasando a tu sitio, el manual de qué hacer cuando te hackean la web ordena todo el proceso; este artículo se centra en el síntoma japonés.

Por qué solo lo ves en Google y no al entrar en tu web

Esta es la parte que más desconcierta y tiene una explicación técnica muy concreta: se llama cloaking o encubrimiento. El código que han inyectado mira quién está pidiendo la página antes de decidir qué devolver.

Si quien pide la página es un visitante normal con un navegador español, devuelve tu web de siempre. Si quien pide la página es el rastreador de Google —se identifica en la cabecera User-Agent como Googlebot— devuelve la página en japonés. A veces también se activa cuando llegas desde un enlace de resultados de búsqueda, mirando la cabecera Referer.

Resultado: tú nunca lo ves, tus clientes tampoco, y Google lleva semanas indexando basura en tu dominio. Puedes comprobarlo desde cualquier ordenador con curl:

curl -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" https://tudominio.es/ | head -40

Compáralo con lo que devuelve sin ese parámetro. Si el contenido cambia, tienes encubrimiento confirmado. No es una prueba definitiva —hay variantes que solo responden a rangos de IP reales de Google— pero cuando salta, salta claro.

Comprobarlo con site: y con la inspección de URLs

Antes de tocar nada, mide el tamaño del problema. Son cinco minutos.

El operador site:

En Google, busca site:tudominio.es. Verás el listado de lo que Google tiene indexado de tu dominio. Ve pasando páginas de resultados. Si aparecen títulos en japonés, ya sabes. Afina la búsqueda añadiendo cualquier término japonés que hayas visto en tus resultados, por ejemplo site:tudominio.es 財布.

Search Console te da el número real

El operador site: es orientativo. El dato serio está en Search Console, en Indexación > Páginas. Si tu web tiene 40 páginas y ahí pone que hay 3.800 indexadas, ya no hace falta contar más. Entra también en Rendimiento y ordena por consultas: verás términos japoneses con impresiones.

Luego coge una de esas URLs raras y pásala por la Inspección de URLs, arriba del todo. Pulsa Probar URL publicada y después Ver página probada > HTML. Ahí ves exactamente el código que Google recibe de tu servidor. Si aparece el japonés, tienes la prueba de que la inyección está en tu alojamiento y no en un tercero.

Los administradores falsos que casi siempre lo acompañan

Ve a Usuarios > Todos los usuarios en tu WordPress y mira la lista de administradores. En la mayoría de casos que hemos visto aparece alguno que no reconoces, con un nombre de usuario aleatorio y un correo de dominio gratuito.

Cuidado con una trampa habitual: algunas variantes ocultan al usuario del listado del panel, de forma que existe en la base de datos pero no lo ves en pantalla. Para descartarlo, entra en phpMyAdmin y ejecuta:

SELECT ID, user_login, user_email, user_registered FROM wp_users ORDER BY user_registered DESC;

Si el número de filas no coincide con lo que ves en el panel, tienes usuarios escondidos. Ojo: el prefijo wp_ puede ser otro en tu instalación; lo tienes en wp-config.php en la línea $table_prefix.

No borres nada todavía: apunta los ID, los correos y las fechas de alta. Esas fechas te dicen aproximadamente cuándo entraron y te sirven para buscar ficheros modificados a partir de ese día. Si el atacante también te ha dejado fuera del panel, el proceso completo para recuperar el control está en qué hacer cuando te han cambiado la contraseña de administrador.

Eliminar las páginas generadas y el sitemap falso

Aquí hay que distinguir dos escenarios, porque la limpieza es distinta.

Si las páginas están en la base de datos

Algunas variantes crean entradas reales de WordPress. Las ves en Entradas > Todas las entradas, normalmente publicadas por el usuario falso y con fechas concentradas en pocos días. Filtra por ese autor, selecciona todo y envíalo a la papelera. Después vacía la papelera; si dejas las entradas ahí, siguen en la base de datos.

Si las páginas no existen como contenido

Es el caso más frecuente. Las URLs en japonés no están en Entradas ni en Páginas porque se generan al vuelo desde un fichero PHP o desde una regla de reescritura. Comprueba el .htaccess de la raíz de tu web: debe contener solo el bloque estándar entre # BEGIN WordPress y # END WordPress. Cualquier RewriteRule fuera de ese bloque, apuntando a un fichero PHP con nombre raro, es lo que estás buscando.

El sitemap falso

Casi siempre hay un mapa del sitio propio para que Google encuentre rápido las páginas nuevas. Busca en la raíz ficheros tipo sitemap.xml, sitemap-index.xml o nombres inventados que no correspondan al plugin de SEO que usas. Ábrelos en el navegador: si listan URLs japonesas, bórralos. Revisa también tu robots.txt: si tiene una línea Sitemap: apuntando a un fichero que tú no has configurado, quítala.

Y mira en Search Console, en Indexación > Sitemaps. Si hay un sitemap enviado que no reconoces, elimínalo desde ahí y revisa quién tiene permisos sobre la propiedad en Configuración > Usuarios y permisos.

Encontrar el archivo que las regenera cada noche

Esta es la parte que separa una limpieza real de un parche que dura dos días. Si borras las páginas y no encuentras el generador, en 24 o 48 horas vuelven.

Con acceso SSH, empieza por los ficheros modificados desde la fecha de alta del usuario falso:

find /home/usuario/public_html -name "*.php" -newermt "2026-08-01" -ls

Después busca los patrones típicos de código ofuscado:

grep -rlE "base64_decode|eval(|gzinflate|str_rot13|preg_replace(.*/e" /home/usuario/public_html --include="*.php"

Sé honesto contigo mismo al leer los resultados: algunos plugins legítimos usan base64_decode para cosas normales. Lo que delata a un fichero malicioso es la combinación: nombre extraño, fecha reciente, una única línea larguísima de texto sin saltos y una ubicación donde no pinta nada. Los sitios donde más aparecen:

• wp-content/uploads/ y sus subcarpetas por años. Ahí no debería haber ningún fichero .php. Ni uno.
• wp-content/mu-plugins/. Es una carpeta de plugins que se cargan siempre y no se pueden desactivar desde el panel. Si existe y tú no la creaste, sospecha.
• wp-includes/, imitando nombres del núcleo con una letra cambiada.
• La raíz, con nombres como wp-info.php o similares que parecen de WordPress pero no lo son.

Revisa además las tareas programadas, que es el mecanismo habitual de regeneración. En el panel de tu hosting, en Trabajos cron, no debería haber nada que tú no hayas puesto. Y dentro de WordPress, el cron interno guarda sus tareas en la base de datos:

SELECT option_value FROM wp_options WHERE option_name = 'cron';

Si ves nombres de tarea que no corresponden a ningún plugin instalado, ahí tienes el temporizador. Todo esto forma parte de un trabajo más amplio: localizar las puertas traseras que han dejado dentro es lo que evita que dentro de un mes estemos igual.

Si no tienes SSH ni te ves capaz de distinguir un fichero legítimo de uno inyectado, para aquí. Este es el punto donde conviene que lo mire alguien con experiencia, porque borrar un fichero del núcleo por error deja la web caída y borrar de menos deja la puerta abierta. Una limpieza profesional en España ronda los 500 euros, y comparado con perder el posicionamiento de años suele salir a cuenta.

Pedir la retirada de esas URLs en Search Console

Cuando la web ya esté limpia —y solo entonces— toca hablar con Google. El orden es importante: si pides la retirada con las páginas todavía activas, vuelven a indexarse.

1. Comprueba que las URLs devuelven 404 o 410. Coge tres o cuatro de las URLs japonesas y ábrelas. Si siguen cargando, no has terminado la limpieza.
2. Usa la herramienta de Retiradas (Indexación > Retiradas > Nueva solicitud). Puedes retirar un prefijo completo, por ejemplo tudominio.es/wp-content/uploads/2025/, y se lleva por delante todo lo que cuelgue de ahí.
3. Ten claro que esa retirada es temporal. Oculta las URLs unos meses; es un parche mientras Google reprocesa. Lo que las elimina de verdad es que devuelvan 404 y que Google las vuelva a rastrear.
4. Si te salió el aviso de «Este sitio puede estar comprometido», entra en Seguridad y acciones manuales > Problemas de seguridad y solicita la revisión. Explica en dos líneas qué encontraste y qué has hecho. Las revisiones automáticas suelen ser rápidas; las manuales tardan más.

No esperes recuperar tus posiciones al día siguiente. Google tiene que rastrear de nuevo miles de URLs y recalcular. Ese proceso de recuperación tiene sus propios pasos, y los tienes desarrollados en cómo recuperar el posicionamiento después de un hackeo. Mientras tanto, si empiezas a ver en Search Console páginas indexadas que no reconoces pero que ya no están en japonés, revisa también de dónde salen esas páginas que tú no has creado: suele ser el mismo generador con otro idioma.

Antes de dar el caso por cerrado

Dos semanas después de la limpieza, vuelve a hacer el site: y vuelve a mirar el número de páginas indexadas en Search Console. Si la cifra ha bajado y sigue bajando, vas bien. Si se ha estabilizado en un número alto o vuelve a subir, quedó algo dentro y hay que volver al apartado del generador.

Escanea tu web gratis con PathScan y mira cuántas URLs ajenas hay indexadas en tu dominio. Es una comprobación desde fuera, sin registro y sin tocar nada de tu web: te dice qué está viendo Google de tu dominio ahora mismo, que suele ser bastante distinto de lo que ves tú al entrar.