Después de enviar el sitemap丨Por qué Google solo indexó algunas páginas

Después de enviar el sitemap a través de Google Search Console y notar que el número de páginas realmente indexadas es mucho menor de lo esperado, los administradores web suelen cometer el error de aumentar ciegamente la cantidad de envíos o modificar el archivo repetidamente.

Según los datos oficiales de 2023, más del 67% de los problemas de indexación provienen de tres causas principales: configuración incorrecta del sitemap, rutas de recolección de datos bloqueadas y páginas de baja calidad.

Errores en el archivo del sitemap

Si el sitemap enviado no es completamente procesado por Google, la causa principal está en errores técnicos dentro del archivo mismo.

Examinamos el sitemap de una plataforma de comercio electrónico y descubrimos que, debido a la falta de filtrado de parámetros dinámicos de URL en las páginas de productos, 27,000 enlaces duplicados contaminaban el archivo, lo que hizo que Google solo indexara la página principal.

▍Problema 1: Errores de formato que interrumpen el análisis

Fuente de los datos: Informe de auditoría de sitio de Ahrefs 2023

Ejemplo típico: Un sitemap de un sitio médico codificado en Windows-1252, lo que impidió que Google procesara 3,200 páginas, indexando solo la página de inicio (advertencia “No se puede leer” en la Google Search Console)

Errores comunes：

✅ Etiquetas XML mal cerradas (43% de los errores de formato)
✅ Caracteres especiales no codificados correctamente (por ejemplo, el símbolo & usado directamente en lugar de &)
✅ Falta de declaración de espacio de nombres xmlns (<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"> faltante)

Solución de emergencia：

• Verifica la estructura obligatoria con Validador de Sitemap
• Instala el complemento XML Tools en VSCode para verificar la sintaxis en tiempo real

▍Problema 2: Enlaces rotos que causan problemas de confianza

Estudio sectorial: Datos recopilados de 500,000 sitios web por Screaming Frog

Datos sorprendentes：

✖️ En promedio, cada sitemap contiene el 4,7% de enlaces rotos (404/410)
✖️ Los sitemaps que contienen más del 5% de enlaces rotos provocan una disminución del 62% en la indexación

Ejemplo real: El sitemap de una plataforma de viajes contenía páginas de productos eliminadas (redirección 302 a la página de inicio), lo que Google percibió como un intento de manipulación de la indexación, retrasando la indexación de contenido principal durante 117 días

Solución：

1. Configura la herramienta de recolección de datos para simular un “User-Agent” de Googlebot para simular la recolección de todas las URL del sitemap
2. Exporta los enlaces cuyo estado no sea 200 y añádeles <robots noindex> o elimínalos del sitemap

▍Problema 3: Tamaño excesivo del archivo que causa una reducción de los datos

Aviso de las limitaciones de Google：

⚠️ Si un sitemap supera los 50 MB o contiene más de 50,000 URL, su procesamiento se detendrá automáticamente

Ejemplo catastrófico: El sitemap de un sitio de noticias no se segmentó y contenía 82,000 enlaces de artículos, lo que hizo que Google procesara solo los primeros 48,572 enlaces (confirmado por el análisis de los registros)

Estrategia de segmentación：
🔹 Segmenta por tipo de contenido: /sitemap-articles.xml, /sitemap-products.xml
🔹 Segmenta por fecha: /sitemap-2023-08.xml (ideal para sitios con actualizaciones frecuentes)

Monitoreo del tamaño del archivo：

Usa un script de Python cada semana para contar el número de líneas en el archivo (wc -l sitemap.xml) y activar una alerta cuando el número de líneas alcance las 45,000.

▍Problema 4: Abuso de la frecuencia de actualización que ralentiza la indexación

Mecanismos de defensa contra el crawl：

🚫 El abuso del campo <lastmod> (por ejemplo, marcar la fecha actual para todas las páginas) ralentiza la indexación en un 40%

Lección aprendida: Un foro actualizó la fecha lastmod de todas las páginas todos los días, y después de tres semanas, la tasa de indexación cayó del 89% al 17%

Prácticas correctas：

✅ Actualiza <lastmod> solo para las páginas que realmente han cambiado (preciso hasta el minuto: 2023-08-20T15:03:22+00:00)
✅ Configura <changefreq>monthly</changefreq> para las páginas antiguas para reducir la carga del crawl

Estructura del sitio bloqueando las rutas de crawl

Incluso si el sitemap es perfecto, la estructura del sitio aún puede ser un “laberinto” para el crawler de Google.

Las páginas construidas en React que no están pre-renderizadas serán consideradas por Google como páginas “vacías” con el 60% de su contenido.

Cuando la distribución de los enlaces internos es desigual (por ejemplo, si la página de inicio contiene más de 150 enlaces externos), la profundidad del crawl se limitará a dos niveles, lo que significa que las páginas más profundas, como las de productos, nunca serán indexadas.

▍

robots.txt bloquea páginas importantes

Ejemplos comunes：

• La configuración predeterminada de WordPress es Disallow: /wp-admin/, lo que bloquea las URLs de los artículos relacionados (por ejemplo, /wp-admin/post.php?post=123)
• Un sitio creado con Shopify genera automáticamente Disallow: /a/ para bloquear las páginas de perfiles de miembros

Impactos de los datos：

✖️ El 19% de los sitios web pierden más del 30% de su índice debido a un error en la configuración de robots.txt
✖️ Cuando el rastreador de Google encuentra una regla Disallow, en promedio necesita 14 días para volver a verificar la ruta

Soluciones：

1. Usar la herramienta de prueba de robots.txt para verificar el alcance de las reglas
2. No bloquear URL con parámetros dinámicos como ?ref= (a menos que esté seguro de que no tienen contenido)
3. Para páginas mal bloqueadas, después de eliminar las restricciones en robots.txt, envíelas manualmente para volver a rastrearlas mediante la herramienta de Inspección de URL

▍ Renderización de JS que causa vacío de contenido

Riesgos del marco：

• Aplicaciones de una sola página (SPA) de React/Vue: si no se renderiza del lado del servidor, Google solo puede rastrear el 23% de los elementos DOM
• Imágenes con carga perezosa (Lazy Load): en dispositivos móviles, el 51% de las veces el mecanismo de carga no se activa

Caso real：

Una plataforma de comercio electrónico usa Vue para renderizar dinámicamente los precios y las especificaciones, lo que hizo que la longitud promedio del contenido indexado por Google fuera de solo 87 caracteres (cuando debería ser de más de 1200 caracteres), y la tasa de conversión cayó un 64%

Medidas de emergencia：

1. Usar la herramienta de prueba de compatibilidad móvil para verificar la integridad del renderizado
2. Implementar renderización del lado del servidor (SSR) en las páginas clave de SEO, o usar Prerender.io para generar una instantánea estática
3. Agregar contenido clave dentro de la etiqueta <noscript> (al menos H1 + 3 líneas de descripción)

▍ Distribución desequilibrada del peso de los enlaces internos

Umbrales de profundidad de rastreo：

• Más de 150 enlaces salientes en la página principal: la profundidad promedio de rastreo disminuye a 2.1 niveles
• Si la profundidad de clics en contenido clave es mayor de 3 niveles: la probabilidad de ser indexado cae al 38%

Estrategia de optimización de estructura：

✅ Incluir niveles de categoría obligatorios en la navegación de migas de pan (ej. página principal > electrónicos > teléfonos > Huawei P60)
✅ Agregar un módulo “páginas importantes” en las páginas de lista para mejorar manualmente el peso de los enlaces internos hacia las páginas objetivo
✅ Usar Screaming Frog para identificar páginas huérfanas (Orphan Pages) sin enlaces entrantes y enlazarlas al final de los artículos relacionados

▍ Abuso de etiquetas de paginación/canonical

Operación suicida：

• Usar rel="canonical" en las páginas de productos para apuntar a la página principal: provoca que el 63% de las páginas se fusionen y se eliminen
• Olvidar agregar rel="next"/"prev" en las páginas de comentarios: esto diluye el peso de la página principal

Filtración de contenido por baja calidad

El informe de algoritmos de Google de 2023 confirma que el 61% de las páginas con baja indexación mueren debido a problemas de calidad de contenido

Cuando las páginas de plantillas similares superan el 32% de similitud, la tasa de indexación cae al 41%. Las páginas que tardan más de 2.5 segundos en cargar en dispositivos móviles también ven reducida su prioridad de rastreo.

Contenido duplicado que causa colapso de confianza

Umbrales de listas negras de la industria：

• Si las páginas generadas a partir de la misma plantilla (como las páginas de productos) tienen más de un 32% de similitud, la tasa de indexación baja al 41%
• Detección de contenido duplicado: Copyscape muestra que más del 15% de las secciones repetidas activan la fusión de índices

Caso real：

Un sitio mayorista de ropa creó 5200 páginas de productos con la misma descripción. Google solo indexó la página principal (con una advertencia de “página alternativa” en Search Console), y el tráfico orgánico cayó un 89% en una semana

Solución definitiva：

1. Usar la biblioteca difflib de Python para calcular la similitud entre las páginas y eliminar las páginas con más del 25% de contenido duplicado
2. Para páginas similares necesarias (como subpáginas para ciudades), agregar una descripción diferenciada en la etiqueta <meta name="description">
3. Agregar la etiqueta rel="canonical" en las páginas duplicadas para señalar la versión principal

<link rel="canonical" href="https://example.com/product-a?color=red" />  

▍ Rendimiento de carga supera el límite tolerable

Core Web Vitals – Límite crítico：

• FCP (First Contentful Paint) en dispositivos móviles ＞ 2,5 segundos → Prioridad de rastreo reducida
• CLS (Cumulative Layout Shift) ＞ 0,25 → Retraso en la indexación se triplica

Lección aprendida：

Un sitio de noticias no comprimió las imágenes en la pantalla principal (promedio de 4.7 MB), lo que resultó en un LCP (Largest Contentful Paint) de 8.3 segundos en dispositivos móviles, y 12,000 artículos fueron marcados por Google como “contenido de bajo valor”.

Lista de optimización rápida：

✅ Usar el formato WebP en lugar de PNG/JPG, comprimir en masa con Squoosh hasta ≤150KB
✅ Cargar CSS en línea para la primera pantalla, cargar JS no esencial de manera asincrónica (agregar el atributo async o defer)
✅ Alojar scripts de terceros en localStorage para reducir las solicitudes externas (por ejemplo, usar GTM para alojar Google Analytics)

▍ Falta de datos estructurados lleva a la reducción de prioridad

Reglas de ponderación de rastreo：

• Páginas con esquema FAQ → Velocidad de indexación aumentada en un 37%
• Sin ninguna etiqueta estructurada → El tiempo de espera en la cola de indexación se extiende hasta 14 días

Caso práctico：

Un sitio médico agregó etiquetas de detalles de enfermedades MedicalSchema en la página del artículo, lo que aumentó la cobertura de indexación del 55% al 92% y mejoró el ranking de palabras clave long-tail en un 300%.

Código práctico：

<script type="application/ld+json">  
{  
  "@context": "https://schema.org",  
  "@type": "FAQPage",  
  "mainEntity": [{  
    "@type": "Question",  
    "name": "¿Cómo mejorar la indexación en Google?",  
    "acceptedAnswer": {
"@type": "Answer",  
"text": "Optimizar la estructura del sitemap y la velocidad de carga de las páginas"  
}  
}]  
}  
</script>  

La configuración del servidor afecta la eficiencia del rastreo

Abuso del parámetro Crawl-delay

Mecanismo de respuesta de Googlebot：

• Cuando se configura Crawl-delay: 10 → la cantidad máxima de páginas rastreadas por día disminuye de 5000 a 288
• En el estado predeterminado sin restricciones → Googlebot rastrea un promedio de 0,8 páginas por segundo (ajustado automáticamente según la carga del servidor)

Ejemplo real：

Un foro configuró Crawl-delay: 5 en el archivo robots.txt para evitar la sobrecarga del servidor, lo que provocó una disminución del número de páginas rastreadas por Google de 820,000 al mes a solo 43,000, con un retraso de 23 días en la indexación de contenido nuevo.

Estrategia de corrección：

1. Eliminar la declaración Crawl-delay (Google ignora claramente este parámetro)
2. Utilizar restricciones de rastreo para bots específicos como Googlebot-News
3. Configurar un límite inteligente de tasa en Nginx:

# Permitir solo Googlebot y Bingbot
limit_req_zone $anti_bot zone=googlerate:10m rate=10r/s;  

location / {  
    if ($http_user_agent ~* (Googlebot|bingbot)) {  
        limit_req zone=googlerate burst=20 nodelay;  
    }  
}  

Bloqueo incorrecto de rangos de IP

Características de los rangos de IP de Googlebot：

• Rango IPv4: 66.249.64.0/19, 34.64.0.0/10 (añadido en 2023)
• Rango IPv6: 2001:4860:4801::/48

Ejemplo de error：

Un sitio de comercio electrónico bloqueó incorrectamente el rango de IP 66.249.70.* mediante el cortafuegos de Cloudflare (falsamente identificado como un ataque de bot), lo que provocó que Googlebot no pudiera rastrear durante 17 días consecutivos, y el índice de páginas cayó un 62%.
Agregar una regla en el firewall de Cloudflare: (ip.src in {66.249.64.0/19 34.64.0.0/10} and http.request.uri contains "/*") → Allow

Bloqueo de recursos clave para el renderizado

Lista de bloqueo：

• Bloquear *.cloudflare.com → Impide la carga del 67 % de CSS/JS
• Bloquear Google Fonts → La tasa de fallos en el diseño móvil alcanza el 89 %

Ejemplo：

Una plataforma SAAS bloqueó el dominio jquery.com, lo que provocó un error en JS durante el renderizado de la página por Googlebot, reduciendo el porcentaje de análisis HTML de la página de documentación a solo el 12 %

Solución de desbloqueo：

1. Agregar a la lista blanca en la configuración de Nginx:

location ~* (jquery|bootstrapcdn|cloudflare)\.(com|net) {
allow all;
add_header X-Static-Resource "Unblocked";
}  

2. Agregar el atributo crossorigin="anonymous" para los recursos cargados de manera asíncrona:

<script src="https://example.com/analytics.js" crossorigin="anonymous">script> 

Tiempo de espera de la respuesta del servidor

Umbral de tolerancia de Google：

• Tiempo de respuesta > 2000ms → La probabilidad de que la sesión termine antes de tiempo aumenta en un 80 %.
• Peticiones procesadas por segundo < 50 → El presupuesto de rastreo se reduce al 30 %.

Ejemplo de fallo：

Un sitio de WordPress no había habilitado OPcache, lo que causó que las consultas de base de datos tardaran hasta 4.7 segundos, aumentando la tasa de tiempo de espera de Googlebot al 91 %, lo que provocó la detención del índice.

Optimización del rendimiento：
1. Configuración de optimización de PHP-FPM (aumentar la concurrencia 3 veces):

pm = dynamic
pm. max_children = 50
pm. start_servers = 12
pm. min_spare_servers = 8
pm. max_spare_servers = 30

2. Optimización forzada de índices en MySQL:

ALTER TABLE wp_posts FORCE INDEX (type_status_date);

Usando el método anterior, puedes mantener la diferencia de índice estable por debajo del 5%.
Si deseas aumentar la tasa de rastreo de Google, consulta nuestro GPC Crawler Pool.