¿Google solo indexa tu página de inicio? Cómo diagnostico un sitio que Google dejó de indexar
¿Google solo indexa tu página de inicio tras limpiar un hackeo? Descartá spam residual y bloqueos técnicos y tratalo como un problema de calidad.
Limpiás el hackeo, pasan los meses y Google parece haberse quedado en la puerta. Si seguís con solo la página de inicio indexada, primero descartá restos del ataque y un bloqueo técnico, porque son las hipótesis más baratas de comprobar. Si ambas quedan descartadas, tratá el caso como una reevaluación de calidad del sitio completo: la recuperación puede llevar meses y Solicitar indexación no resuelve el problema de fondo.
Para una caída de todo el sitio de un día para otro, empezá por la guía para una desaparición repentina de Google. Acá el problema es más específico: las páginas internas siguen afuera del índice mucho después de la limpieza.
Yo separo tres hipótesis y las pruebo en este orden. La tabla es mi método, no un protocolo de Google.
| Señal | A qué apunta | Primera comprobación |
|---|---|---|
| Problemas de seguridad muestra contenido hackeado, o las URL de spam responden 200 | Hackeo residual | Corregir todas las instancias y solicitar revisión |
| Aparecen URL de spam en sitemaps o listas de indexación | Restos del ataque | Quitarlas del sitemap. Devolver 404 o 410 |
| La prueba en vivo detecta noindex, bloqueo por robots.txt o canonical al inicio | Bloqueo técnico | Corregir la directiva y volver a probar |
| El HTML renderizado no contiene los enlaces internos | Renderizado o descubrimiento | Comprobar enlaces <a href> rastreables |
| Muchas páginas figuran como rastreadas pero sin indexar. Las pruebas están limpias | Reevaluación de calidad | Revisar, mejorar o consolidar el sitio |
| La caída coincide con un core update y no con el hackeo | Calidad y fechas superpuestas | Comparar fechas y trabajar con un horizonte de meses |
Qué dijo Mueller sobre tener solo la página de inicio indexada
El 3 de noviembre de 2026, Barry Schwartz publicó un intercambio de Bluesky. Sarah Blocksidge describió un cliente hackeado el año anterior: seguía con solo el inicio indexado tras la limpieza y dificultades para que Google rastreara enlaces internos.
John Mueller aclaró que faltaba información. Su interpretación inicial fue esta, en el original:
“this sounds like a general quality issue that might be unrelated to the hack (unless the hack was in place for a long time - ca many months). Times timing makes it hard to notice, eg when the hack & a core update happen together.” Search Engine Roundtable
Planteó un problema de calidad posiblemente ajeno al hackeo, salvo que hubiera durado meses. Un core update simultáneo complica esa distinción.
Schwartz agrega que una limpieza incompleta o un problema técnico siguen siendo posibles. Mueller no tenía detalles para descartarlos.
Expert Insight
Sacar el spam visible no devuelve automáticamente la confianza de Google en todo el sitio. Mi lectura de una página de inicio que sobrevive es que puede haber confianza para mostrar la marca, pero no la misma para incluir sus páginas internas. Antes de actuar sobre esa interpretación, comprobaría qué las está dejando afuera.
Primero, comprobá que el hackeo haya terminado
Abrí Problemas de seguridad en Search Console. Google lo indica como referencia para verificar los problemas de seguridad reportados y su resolución. Revisá Acciones manuales por separado: son informes distintos, con alcances diferentes. Documentación de Problemas de seguridad
Yo buscaría evidencia que no dependa únicamente de las URL de ejemplo:
- Consultas como
site:example.com pharmacyysite:example.com/wp-admin/para encontrar patrones ajenos al sitio. - URL sospechosas en exclusiones de indexación, sitemaps XML y sitemaps del CMS.
- Pedidos a antiguas rutas de spam en logs del servidor o CDN.
Las URL inyectadas deberían responder 404 o 410, sin seguir devolviendo 200 ni redirigir todas al inicio. Para detectar contenido condicionado, compará una descarga normal con otra que use referente de Google y user-agent Googlebot. Reemplazá la dirección de ejemplo por la página que estés comprobando:
curl -L 'https://example.com/'
curl -L -e 'https://www.google.com/' -A 'Googlebot' 'https://example.com/'
Buscá enlaces o texto inyectado. Google documenta este tipo de cloaking y recomienda también Inspección de URL. Una comparación limpia no demuestra que todas las páginas estén limpias.
Pasá administradores, plugins o reglas de reescritura desconocidos al responsable de seguridad. Acá comprobamos qué se sirve y puede indexarse.
Las muestras del informe no son completas. Corregí todas las instancias antes de Solicitar revisión. Google indica un plazo de días a semanas y pide esperar la decisión antes de reenviar. Consultá el playbook de recuperación de penalizaciones.
Bloqueos técnicos que se parecen a un problema de calidad
Haría una prueba en vivo de cinco a diez URL internas importantes. Comprobá permiso de rastreo, permiso de indexación, contenido renderizado y canonical declarada frente a la elegida por Google. El informe de indexación de páginas explica los motivos de exclusión y la consulta de la canonical seleccionada.
Revisá especialmente lo que cambió al restaurar el sitio: carpetas bloqueadas en robots.txt, noindex aplicado a una plantilla, canonicals al inicio o redirecciones masivas hacia esa página. Sumá respuestas 5xx, soft 404 y un sitemap que solo incluya el inicio.
Mirá el HTML renderizado. ¿Están el contenido y los enlaces internos? Google explica que los enlaces rastreables generalmente necesitan un elemento <a> con atributo href. JavaScript puede insertarlos. Una navegación basada solamente en onclick no es el marcado recomendado.
Cada página importante debería recibir un enlace desde otra página del sitio. Que el menú funcione en tu navegador no confirma qué enlaces ve Google.
Podés ordenar la revisión con el playbook de indexación y rastreo. Para el aspecto de renderizado, tenés el caso de renderizado y rastreo inmobiliario.
Poné el hackeo y las actualizaciones en una misma línea de tiempo
Anotá el inicio del ataque, su detección, la limpieza y el resultado de la revisión de seguridad. Sumá cambios de robots.txt, canonicals y plantillas, además de las fechas de core updates y spam updates anunciados. Debajo, alineá páginas indexadas e impresiones.
Si las exclusiones empiezan con la limpieza, revisaría qué cambió al restaurar. Si arrancan con un core update, la hipótesis de calidad gana peso. Una coincidencia ayuda a orientar la investigación, pero no demuestra la causa.
Consultá el análisis de core updates y el artículo sobre el spam update de agosto de 2026. Usá las fechas correspondientes al historial del sitio.
Google aclara que los core updates no apuntan a sitios concretos. Para comparar períodos, recomienda esperar al menos una semana completa desde el final y contrastar con una semana anterior al inicio. Guía de core updates
Qué cambiaría si la hipótesis de trabajo es calidad
Con seguridad y técnica comprobadas, revisaría el conjunto. Muchas páginas rastreadas sin indexar apoyan esa dirección, pero el estado no prueba calidad por sí solo.
Para las descubiertas sin rastrear, Google describe una URL encontrada cuyo rastreo se pospuso, habitualmente porque podía sobrecargar el sitio. Comprobá esas condiciones antes de usar ese estado como evidencia sobre el contenido. Explicación de los estados
Buscaría plantillas de poco valor o casi duplicadas, páginas de ubicación o etiquetas que funcionen como páginas puerta, versiones de backups antiguos y contenido copiado durante el ataque. Definí qué páginas importantes necesitan una mejora y cuáles conviene consolidar. El artículo sobre contenido de poco valor aporta contexto sin equiparar una exclusión con una acción manual.
Google recomienda evaluar todo el sitio ante caídas grandes y sostenidas, evitar arreglos rápidos y dejar la eliminación de contenido como último recurso. Orientación sobre core updates
Yo acompañaría esas mejoras con un sitemap de URL importantes y enlaces desde el inicio y las páginas de agrupación relevantes. Repetir Solicitar indexación no agrega valor al contenido ni corrige una señal de calidad. Para páginas rastreadas sin indexar, Google dice que no hace falta reenviarlas al rastreo. Informe de indexación
Cuánto puede tardar y qué miraría en Search Console
Google explica que algunos cambios pueden reflejarse en días, pero confirmar una mejora sostenida del sitio puede llevar varios meses. Si pasa ese tiempo sin efecto, quizá haya que esperar otro core update. También existen actualizaciones menores no anunciadas. Ninguna asegura una recuperación. Plazos según Google
Mi seguimiento semanal sería este:
- Recuentos de indexadas, rastreadas sin indexar y descubiertas sin indexar, filtrados por un sitemap de URL clave.
- Inspección de diez páginas importantes, con estado de indexación y canonical seleccionada.
- Impresiones de páginas distintas del inicio en Rendimiento.
- Solicitudes y códigos de respuesta en Estadísticas de rastreo, con Seguridad y Acciones manuales sin incidencias.
Google permite enfocar la validación con un sitemap de páginas importantes. Las listas de ejemplo tienen un límite de 1.000 URL. No necesariamente muestran todo lo afectado. Documentación de indexación
Separá actividad de rastreo de visibilidad. Más solicitudes no confirman que las páginas internas hayan vuelto al índice. Esa distinción está desarrollada en rastreo de Googlebot frente a clics.
Mi checklist corto para ordenar la recuperación
Mi orden de trabajo:
- Resolver hallazgos de seguridad y todas las instancias inyectadas.
- Verificar directivas, canonicals, respuestas y enlaces renderizados en URL clave.
- Comparar limpieza, cambios del sitio y fechas de actualizaciones.
- Mejorar o consolidar páginas importantes, sin borrar por reflejo.
- Medir exclusiones, URL de muestra e impresiones internas cada semana.
Preguntas frecuentes
¿Por qué Google solo indexa mi página de inicio?
Puede quedar un hackeo residual, existir un bloqueo técnico o haber una reevaluación de calidad. Primero descartaría las dos primeras hipótesis. Mueller planteó calidad como una lectura inicial, sin tener detalles suficientes para confirmar el caso.
¿Un hackeo puede dejar páginas afuera después de la limpieza?
Sí, una limpieza incompleta puede dejar URL inyectadas o contenido oculto según quién acceda. Mueller también mencionó ataques que duraron muchos meses. Si hubo un core update al mismo tiempo, no alcanza con atribuir todo al hackeo.
¿Conviene seguir usando Solicitar indexación?
La repetición no corrige bloqueos técnicos ni calidad. Google indica que no hace falta reenviar al rastreo las páginas que ya aparecen como rastreadas sin indexar. Trabajá sobre la causa que puedas comprobar.
¿Qué significa “Rastreada: actualmente sin indexar” en este caso?
Google rastreó la página, pero no la indexó. Puede incorporarla más adelante o no hacerlo. Cuando ocurre a escala y las pruebas están limpias, yo lo tomo como motivo para revisar el valor del conjunto, no como prueba de penalización.
¿Cuánto tarda la recuperación por un problema de calidad?
Google habla de varios meses para confirmar mejoras sostenidas del sitio. En algunos casos puede hacer falta esperar otro core update. No hay una fecha fija ni un resultado que puedas dar por hecho.
¿Necesito una solicitud de reconsideración?
Una hipótesis de calidad no equivale a una acción manual reportada. Comprobá Acciones manuales por separado. Si hay problemas de seguridad reportados, corregilos por completo y solicitá revisión desde ese informe. Es un proceso distinto de la reevaluación de calidad.
Terminar la limpieza no asegura que Google vuelva a indexar las páginas internas.
En Growing Search podemos ayudarte con una auditoría SEO o asesoría de SEO técnico. Empezá por las páginas importantes para tu negocio y por evidencia verificable.
Sobre el autor
