Google indexó tu web en un subdominio equivocado: cómo limpiarlo

El 23 de octubre de 2026 alguien que gestiona una web publicó en r/DoSEO y r/TechSEO un caso que se repite mucho: Google había indexado entradas del blog en ftp.example.com en lugar de www.example.com, el desarrollador eliminó el subdominio del servidor y las URL de FTP seguían en los resultados. John Mueller, de Google, contestó a los quince minutos. Pasa igual con staging., dev., la IP del servidor o un subdominio de una configuración antigua, y da igual la plataforma: WordPress, Shopify con dominio propio, un frontend headless o una web estática.

La limpieza depende de tres cosas: qué devuelve hoy el nombre antiguo, qué propiedad de Search Console puede verlo y qué señales recibe el dominio principal. Todos los plazos de este artículo salen de la documentación de Google Search Central.

#Por qué Google indexó la web en el subdominio ftp o de pruebas

Quien preguntaba había revisado la inspección de URL. La dirección FTP estaba indexada, con rastreo permitido y obtención correcta. Su gemela en www era desconocida para Google, sin sitemap ni página de referencia. El detalle que lo explica:

El canónico declarado por el usuario apuntaba a la propia URL de FTP. El canónico elegido por Google también era la URL de FTP.

(u/Gullible-Winter294, r/DoSEO, 23 de octubre de 2026, traducción propia)

Para llegar ahí hacen falta tres condiciones a la vez. Un registro DNS (ftp, staging o un comodín) apunta al mismo servidor que producción. El servidor responde a ese nombre con la web de producción porque es el host virtual por defecto. Y la plantilla construye la etiqueta canonical con el nombre de la petición en vez de una URL base configurada, así que cada copia se declara original. Google tiene dos páginas idénticas que dicen ser la buena y elige una de ellas.

#Qué devuelve ahora el subdominio antiguo

Antes de tocar nada, mira qué recibe Google cuando vuelve. Una de las respuestas lo dejó claro:

Primero comprueba qué devuelve de verdad ahora una URL HTTPS antigua: un fallo de DNS no es un 404.

(u/inevidimka, r/DoSEO, 23 de octubre de 2026, traducción propia)

dig +short ftp.example.com
curl -sI https://ftp.example.com/blog/articulo-ejemplo

Si dig no devuelve nada, el nombre ya no resuelve. Si devuelve una IP, curl te dice si obtienes un 200 con la página entera, un 404 o 410, una redirección o un error TLS porque el certificado no cubre ese nombre. Prueba varias URL que Google muestre de verdad, no solo la portada. La guía de errores de DNS y de red de Google usa dig igual para revisar registros A, CNAME y NS.

La trampa habitual: borrar el host virtual y dejar el registro DNS. Entonces contesta la web por defecto del servidor, casi siempre la misma que en www, y vuelves al punto de partida.

#Cuánto tarda Google en quitar URL con 404 o error de DNS

La documentación de códigos HTTP dice que las URL ya indexadas que devuelven 4xx se eliminan del índice. Todos los 4xx salvo el 429 se tratan igual, así que 404 y 410 tienen el mismo efecto, y la frecuencia de rastreo de esas URL baja poco a poco. Los errores de DNS, los tiempos de espera agotados y las conexiones cortadas cuentan como errores 5xx, y la guía de DNS afirma que las URL indexadas inaccesibles se eliminan del índice en pocos días.

En los dos casos Google tiene que volver a pasar por la URL, y de ahí la espera. Un comentario dio una cifra:

Google desindexará cuando vea el error 404. Desindexar puede tardar hasta 3 meses

(u/KindlyConnection4420, r/DoSEO, 23 de octubre de 2026, traducción propia)

Google no publica ese plazo. Una URL poco importante en un host muerto puede esperar un tiempo a que el robot vuelva, pero tres meses son la experiencia de una persona, no una norma.

#Cómo redirigir el subdominio antiguo con 301

Si los mismos artículos están en el dominio principal, la redirección página a página es mejor arreglo que la retirada. Mueller la dio como alternativa:

Otra opción: cambia el DNS para que apunte a un sitio donde puedas hacer una redirección 301 de todas las URL a www y, si quieres, envía una solicitud de cambio de dirección en Search Console.

(u/johnmu, r/TechSEO, 23 de octubre de 2026, traducción propia)

La guía de canonicalización clasifica las redirecciones como señal fuerte de que el destino debe ser el canónico, y además arrastran los enlaces que apuntan al host equivocado. Tres condiciones prácticas:

• El nombre tiene que resolver y tener un certificado válido para él, o el rastreador se queda en el error TLS sin ver el 301.
• Cada URL a su pareja. Mandarlo todo a la portada tira la señal de cada página.
• No las quites. La guía de traslado de sitios habla de, en general, al menos un año, y la herramienta de cambio de dirección pide como mínimo 180 días.

Según esa misma guía, en una web mediana Google puede tardar unas semanas o más en mostrar las URL nuevas en lugar de las antiguas.

#Cómo verificar y retirar un subdominio borrado en Search Console

Lo primero que escribió Mueller fue “verifica con DNS” (traducción propia). La herramienta de retirada y la inspección de URL solo funcionan con URL de una propiedad de la que seas propietario, y un host que ya no sirve nada no puede alojar el archivo HTML de verificación. Una propiedad de dominio se verifica con un registro DNS (TXT o CNAME) y cubre todos los subdominios y los protocolos http, https y ftp. Verifica example.com como propiedad de dominio y ftp.example.com, staging.example.com y cualquier subdominio olvidado quedan dentro, tengan servidor detrás o no.

Con la propiedad verificada, la herramienta de retirada permite ocultar todas las URL con un prefijo, por ejemplo https://ftp.example.com/. La ayuda de Google aclara que un prefijo en staging no afecta a www ni al dominio sin www. Sobre la duración, la versión en español de la ayuda es explícita:

Las solicitudes que se aprueban duran solo unos seis meses. Una vez transcurrido ese periodo, tu información podrá volver a aparecer en los resultados de la Búsqueda de Google.

El artículo sobre retirar páginas dice que la solicitud surte efecto en menos de un día. Más límites de la misma ayuda: la herramienta oculta resultados pero no frena el rastreo ni borra nada para siempre; lo definitivo es un 404 o 410, una contraseña o noindex. Si la URL ya devuelve 404 o 502/503 al enviar la solicitud, Google da la página por eliminada y deja caducar la solicitud. Y Google desaconseja usarla para elegir la versión correcta de una web, porque puede ocultar todas las versiones de una URL; entre www y sin www, ni lo intentes.

Merece la pena cuando las URL equivocadas hacen daño hoy: una copia de pruebas con precios ficticios, un host de desarrollo con páginas a medias, una IP en los resultados. Para un blog duplicado en ftp. que va a recibir 301 o 404 igualmente, basta la última frase de Mueller: si las URL ya no funcionan, caerán solas (traducción propia).

#Por qué bloquear el subdominio en robots.txt empeora el problema

Poner Disallow: / en el host de pruebas tiene el efecto contrario. La documentación sobre noindex dice que una página bloqueada en robots.txt no se obtiene, así que su regla noindex nunca se lee y la página puede seguir saliendo en los resultados. La guía de canonicalización añade que Google puede indexar URL bloqueadas sin su contenido. Deja el host accesible hasta que se hayan leído el 301, el 404 o el noindex.

#Cómo conseguir que se indexen las URL del dominio principal

Quitar el host equivocado no indexa el bueno. Las URL de www de quien preguntaba no tenían sitemap ni páginas que las enlazaran, así que Google no tenía motivo para pedirlas. Corrige las señales en producción:

• Genera el canonical desde una URL base configurada, para que las páginas de www declaren www las sirva el nombre que las sirva.
• Incluye las URL del dominio principal en el sitemap enviado en la propiedad de producción. Google lo llama señal débil, pero las señales se suman.
• Revisa que enlaces internos, hreflang y URL de Open Graph usen el host principal.
• Haz una prueba en directo de algunas URL de www en la inspección de URL y solicita la indexación de las más importantes.

Si el host equivocado apareció tras un cambio de plataforma, nuestro servicio de migración y el artículo sobre por qué Google revierte migraciones de dominio cubren el mapa de redirecciones. La guía de Search Console e Indexing API explica el informe de páginas para seguir el avance.

#Qué hacer en cada caso: tabla de decisión

#Cómo evitar que Google indexe entornos de pruebas

• Contraseña en todo lo que no sea producción. La guía para controlar lo que compartes dice que la protección con contraseña mantiene el contenido fuera de la búsqueda y, si ya aparece, acaba retirándolo.
• Cabecera X-Robots-Tag: noindex en los hosts de pruebas. La especificación de X-Robots-Tag admite la regla como cabecera HTTP, que también cubre PDF e imágenes. Ponla en la configuración del servidor para ese nombre, no en la aplicación, para que una copia de la base de datos de pruebas a producción no se la lleve.
• Borra el registro DNS cuando borres el host. Un CNAME a un servicio que ya no usas es el escenario clásico de toma de subdominio: MDN describe cómo alguien reclama el nombre abandonado en el proveedor y publica su propio contenido en tu subdominio.
• Evita el DNS comodín si no lo necesitas. La documentación de Cloudflare explica que * responde por cualquier nombre sin registro propio. Con un host virtual por defecto, cualquier errata en un subdominio sirve tu web.
• Haz que el host por defecto rechace nombres desconocidos, con un 404 o cerrando la conexión.

La configuración de servidor para la contraseña y la cabecera noindex está en nuestra guía del flujo de staging. Una revisión del sitio incluye el repaso de registros DNS y hosts indexados, y el mantenimiento continuo mantiene esa lista al día tras cada cambio de servidor o de agencia.