SEO técnico: rastreo, indexación y logs (módulo 1 gratis)

Hay webs con buen contenido que no rinden, y el motivo casi nunca es el contenido. Es que Googlebot no llega a la mitad de las URLs, que la plantilla genera diez variantes de cada ficha, que el canonical apunta a una página que ya no existe o que el HTML que recibe el rastreador está vacío porque todo se pinta con JavaScript en el cliente. El SEO técnico es la capa que decide si el resto del trabajo llega a contar. Esta guía es el módulo 1 completo de nuestro curso de SEO técnico avanzado: cómo funciona el rastreo de verdad, qué errores importan y cuáles no, con qué herramientas se diagnostica, cómo se leen los logs del servidor y cuándo el presupuesto de rastreo es un problema tuyo.

Estás leyendo gratis el primer módulo del curso SEO técnico avanzado. No hace falta registrarse.

Contenido de esta página

• Qué problema resuelve el SEO técnico
• Rastrear, renderizar e indexar no son lo mismo
• Errores de rastreo: cuáles duelen y cuáles no
• Herramientas de auditoría técnica
• Logs de servidor: la fuente que no interpreta nada
• Presupuesto de rastreo: cuándo es tu problema

Qué problema resuelve el SEO técnico

El trabajo consiste en diagnosticar con datos, priorizar por impacto y arreglar cosas concretas. No hay teoría de relleno ni promesas de posiciones, entre otras cosas porque casi todo el SEO técnico consiste en quitar obstáculos que alguien puso sin querer, y en resistir la tentación de optimizar cosas que no mueven nada.

Qué vas a poder hacer al terminar el curso

• Leer un informe de indexación de Search Console y saber si un «Descubierta, actualmente sin indexar» es un problema de rastreo, de calidad o de arquitectura.
• Rastrear un sitio y salir con una lista de acciones, no con un volcado de cuarenta mil filas.
• Interpretar las métricas web principales con datos de campo, de usuarios reales, en lugar de perseguir la puntuación de laboratorio.
• Analizar logs de servidor para ver a qué dedica realmente el rastreador su tiempo en tu dominio.
• Implantar datos estructurados que validen y que sirvan para algo.
• Planificar una migración sin perder tráfico por redirigirlo todo a la portada.

Cómo está organizado el curso

1. Fundamentos y rastreo: cómo funciona el proceso, errores frecuentes, herramientas, logs y presupuesto de rastreo. Es este módulo.
2. Rendimiento y métricas web principales: caché, red de distribución, LCP, INP y CLS, recursos y medición.
3. Arquitectura y URLs: 404, estructura, paginación, facetas, silos, redirecciones y migraciones.
4. Datos estructurados: JSON-LD, tipos de Schema.org, validación y resultados enriquecidos.
5. SEO internacional: hreflang, estrategia de dominios y auditoría multilingüe.
6. Auditorías: metodología, priorización, duplicados, canibalización, HTTPS y mantenimiento.

Qué necesitas tener a mano

Acceso a Search Console de un dominio real, aunque sea pequeño; un navegador con herramientas de desarrollador; y, si puedes, un rastreador de escritorio. Para los logs tendrás que pedirlos al proveedor de alojamiento o al equipo de sistemas: pide al menos treinta días en bruto, no un panel resumido, porque un resumen ya ha decidido por ti qué era importante.

Ejercicio 1: tu punto de partida

1. Elige el dominio con el que vas a trabajar durante todo el curso y confirma que tienes la propiedad verificada en Search Console.
2. Anota tres síntomas concretos que te preocupen hoy, del tipo «la mitad del catálogo no aparece indexado».
3. Abre el informe de indexación de páginas y copia los cinco motivos con más URLs. No los interpretes todavía.
4. Comprueba si tienes acceso a los logs del servidor: pregunta al proveedor y apunta la respuesta, sea cual sea.

Qué deberías tener al acabar: un documento con tres síntomas, cinco motivos y una respuesta sobre los logs. Es tu punto de partida y lo compararás al final del curso con el mismo informe.

Rastrear, renderizar e indexar no son lo mismo

La confusión más cara del SEO técnico es tratar «Google no lo ve» como un único problema. Son fases distintas y cada una falla por motivos diferentes. Si no sabes en cuál se atasca tu URL, vas a arreglar lo que no toca y a concluir que el SEO técnico no sirve.

• Descubrimiento: Google se entera de que la URL existe, por enlaces internos, por enlaces externos o por un sitemap.
• Rastreo: hace la petición y recibe una respuesta. Aquí mandan el robots.txt, el código de estado y la velocidad del servidor.
• Renderizado: ejecuta el JavaScript de la página para ver el resultado final. Ocurre en una cola aparte y puede tardar.
• Indexación: decide si guarda la página y con qué canonical. Rastrear no obliga a indexar: Google puede rastrear y descartar.

Cómo descubre Google las URLs

El grueso llega por enlaces internos. Una URL enlazada desde la navegación se descubre casi sola; una que solo aparece en el sitemap tarda más y compite peor. El sitemap es una ayuda, no un sustituto del enlazado: si una página solo existe en el sitemap, le estás diciendo a Google que ni tú mismo la consideras importante.

Cuidado con los enlaces que no son enlaces. Un contenedor con un manejador de clic, o un botón que cambia la URL por JavaScript sin un elemento de enlace real con su atributo href, no es un enlace rastreable. La regla práctica: si no hay href con una URL válida, no cuentes con que se descubra por ahí.

Qué hace el rastreador cuando llega

Googlebot pide la URL con un agente de usuario identificable, respeta el robots.txt y limita su ritmo según lo que aguante tu servidor. Si empiezas a devolver errores de servidor o los tiempos de respuesta se disparan, reduce la frecuencia por su cuenta. Dicho de otro modo: un servidor lento no solo perjudica al usuario, también recorta cuánto se rastrea de tu sitio.

Los códigos de estado son instrucciones, no decoración:

• 200: contenido válido, candidato a indexarse.
• 301: movida de forma permanente; consolida señales en el destino.
• 302: temporal; el original sigue siendo la referencia.
• 404 y 410: no existe. El 410 es más explícito y suele acelerar la retirada.
• 503: no disponible temporalmente. Es la respuesta correcta durante un mantenimiento, nunca un 200 con una página de aviso.

El renderizado y la segunda pasada

Google renderiza con un navegador actualizado, pero el renderizado no es instantáneo ni gratuito. Si tu contenido principal, tus enlaces internos o tu canonical solo existen después de ejecutar JavaScript, dependes de esa segunda fase. Para comprobar qué recibe realmente el rastreador, usa la inspección de URL de Search Console y, dentro de ella, la prueba de la URL publicada: te da el HTML renderizado, una captura y los recursos que no se han podido cargar.

Contrasta siempre dos cosas: el HTML de origen, el que llega en la respuesta, y el HTML renderizado. La diferencia entre ambos es exactamente el trabajo que le estás pidiendo a Google que haga por ti.

Indexar es una decisión, no una consecuencia

Aunque todo lo anterior salga bien, Google puede decidir no indexar: contenido casi idéntico a otro, páginas de poco valor o simplemente un sitio con más URLs de las que merece la pena guardar. Estados como «Rastreada, actualmente sin indexar» o «Descubierta, actualmente sin indexar» no son errores técnicos que se arreglen con una directiva; son un juicio sobre la utilidad de esas páginas, y se responden con contenido o con arquitectura.

Ejercicio 2: en qué fase falla cada URL

1. Elige tres URLs de tu sitio: una importante, una de listado y una profunda del catálogo o del blog.
2. Para cada una, ejecuta la inspección de URL y anota estado de indexación, canonical declarado y canonical elegido por Google.
3. Lanza la prueba de la URL publicada y compara el HTML renderizado con el de origen. Apunta qué aparece solo tras el renderizado.
4. Comprueba si esas tres URLs están enlazadas desde alguna página del sitio o si solo viven en el sitemap.

Qué deberías tener al acabar: una frase por URL diciendo en qué fase falla, si falla: descubrimiento, rastreo, renderizado o indexación. Es el diagnóstico que evita gastar semanas en la capa equivocada.

Errores de rastreo: cuáles duelen y cuáles no

Cuando alguien abre el informe de indexación de páginas por primera vez y ve miles de URLs excluidas, la reacción típica es querer vaciar la lista. Es un mal objetivo. Muchas exclusiones son correctas: una página con noindex deliberado o una URL bloqueada a propósito están haciendo exactamente lo que les pediste. El trabajo consiste en separar lo que sobra de lo que duele.

Los estados que sí importan

• Error del servidor: siempre urgente. Si es intermitente, casi siempre es saturación o un límite de recursos del alojamiento.
• Error de redirección: cadenas largas, bucles o redirecciones a URLs que acaban en 404.
• Bloqueada por robots.txt: revisa si era intencionado. Si esa URL debería estar en el índice, tienes un problema real.
• Página con redirección: normal si el destino es correcto; sospechoso si son URLs que enlazas internamente.
• URL enviada marcada como noindex: contradicción evidente. La estás pidiendo indexar en el sitemap y prohibiendo en la propia página.
• Duplicada, Google eligió un canonical distinto: tu señal no ha convencido. Suele indicar contenido demasiado parecido o enlazado interno incoherente.
• Descubierta, actualmente sin indexar: Google la conoce y no ha ido. Combinación de prioridad baja y presupuesto de rastreo.

El error clásico: bloquear lo que quieres desindexar

Esto merece párrafo propio porque se repite en todos los proyectos. Si una página está bloqueada en el robots.txt, Google no puede rastrearla; y si no puede rastrearla, no puede leer el noindex que has puesto dentro. Resultado: la URL puede seguir apareciendo en resultados, sin descripción, indefinidamente.

El orden correcto es: permitir el rastreo, servir la etiqueta robots con valor noindex o la cabecera equivalente, esperar a que Google reprocese esas URLs y solo entonces, si te interesa ahorrar rastreo, bloquearlas. Nunca al revés.

Cómo diagnosticar sin dar palos de ciego

1. Reproduce el error con una petición limpia, sin cookies ni sesión, desde la línea de comandos. Muchos «errores» solo se dan para usuarios anónimos o para un agente de usuario concreto.
2. Comprueba si es un patrón. Exporta las URLs afectadas y busca el denominador común: un directorio, un parámetro, una plantilla. Un error que afecta a una plantilla entera vale mil veces más que veinte casos sueltos.
3. Mira la fecha. Si todo empezó el mismo día, busca qué se desplegó ese día. Es mucho más rápido que auditar el sitio entero.

Soft 404 y otras confusiones

Un soft 404 es una página que dice «no encontrado» pero responde 200. Google la detecta y la excluye igualmente, así que el daño no es de posiciones: es de ruido, porque gastas rastreo en páginas vacías. Los sospechosos habituales son los buscadores internos sin resultados, los listados de categoría sin productos y las fichas agotadas que se vacían en lugar de devolver contenido o redirigir.

Regla práctica: si la página no tiene contenido útil y no va a volver, devuelve 404 o 410. Si su contenido se ha movido, un 301 a la URL equivalente, nunca a la portada. Si la ausencia es temporal, mantén la página con información real sobre esa situación.

Ejercicio 3: de la exportación a tres acciones

1. Exporta el informe de indexación de páginas y quédate solo con los estados de error y con «Duplicada, Google eligió un canonical distinto».
2. Agrupa las URLs por patrón (directorio, parámetro o plantilla) y cuenta cuántas hay en cada grupo.
3. Coge el grupo más numeroso y valida tres URLs con una petición de solo cabeceras: apunta código de estado, cabeceras de redirección y presencia de directivas para robots.
4. Busca al menos un caso de URL bloqueada en robots.txt que además lleve noindex. Si existe, escribe el orden de pasos para corregirlo.

Qué deberías tener al acabar: tres acciones concretas, cada una con responsable y una frase de justificación. Si no puedes justificar una acción con un dato del informe, todavía no es una acción.

Herramientas de auditoría técnica

Casi todo el mundo instala un rastreador, le da al botón, exporta la hoja de cálculo y se queda mirándola. El problema no es la herramienta: es que un rastreo sin hipótesis previa produce datos, no diagnóstico. Antes de lanzar nada, escribe qué quieres comprobar.

Configurar el rastreo para que sirva de algo

Los ajustes que cambian el resultado de verdad son cuatro, y están en cualquier rastreador serio:

• Renderizado. Por defecto se rastrea el HTML de origen. Si tu web depende de JavaScript, activa el modo con renderizado. Es mucho más lento, así que úsalo sobre una muestra y no sobre el sitio entero.
• Respetar el robots.txt. Déjalo activo para ver lo que ve Google; desactívalo puntualmente cuando necesites saber qué hay detrás de un bloqueo.
• Agente de usuario. Rastrea como Googlebot para detectar bloqueos del cortafuegos o diferencias de contenido no intencionadas, y compara con el rastreo por defecto.
• Conexión con las APIs. Enlaza Search Console y los datos de rendimiento para cruzar cada URL con sus clics y sus métricas de campo en la misma tabla. Es lo que convierte un rastreo en una priorización.

Las cinco vistas que miramos siempre

1. Códigos de respuesta: 3xx, 4xx y 5xx, y sobre todo los enlaces internos que apuntan a ellos.
2. Títulos y meta descripciones: duplicados y ausencias, que suelen delatar plantillas mal montadas.
3. Canonicals: páginas canonicalizadas a otra URL, canonicals a URLs no rastreables y canonicals rotos.
4. Directivas: noindex, nofollow y sus combinaciones inesperadas.
5. Profundidad de rastreo: a cuántos clics de la portada está cada URL. Si tu contenido que genera ingresos está a cinco o seis clics, tienes un problema de arquitectura, no de rastreo.

Alternativas y cuándo usar cada una

• Rastreadores de escritorio (Screaming Frog, Sitebulb). El segundo explica los hallazgos con contexto y prioridad, lo que ayuda cuando el informe lo va a leer alguien que no es SEO.
• Rastreadores en la nube (JetOctopus, Oncrawl, Botify). Imprescindibles a partir de cientos de miles de URLs, y su valor real está en cruzar rastreo con logs.
• Las herramientas de desarrollador del navegador, para una URL concreta: la pestaña de red con la caché desactivada y la del DOM ya renderizado.
• Search Console, la única fuente que te dice lo que Google decidió, no lo que tú deduces. Ninguna herramienta de escritorio sustituye a la inspección de URL.

Interpretar sin exagerar

Un rastreador de escritorio no es Google. Rastrea desde tu conexión, sin el historial del sitio, sin la cola de renderizado y sin criterio de calidad. Sirve para encontrar incoherencias internas: enlaces rotos, canonicals contradictorios, cadenas de redirección, plantillas sin metadatos. No sirve para saber por qué una página no posiciona.

Y desconfía de los paneles de «puntuación SEO». Ninguna herramienta conoce el algoritmo. Un 78 sobre 100 no significa nada; que cuatro mil URLs de catálogo estén canonicalizadas al listado, sí.

Ejercicio 4: tres preguntas antes de rastrear

1. Antes de rastrear, escribe tres preguntas concretas que quieras responder sobre tu sitio.
2. Lanza un rastreo limitado, de una subcarpeta o de unos pocos cientos de URLs, con el agente de usuario de Googlebot y el robots.txt respetado.
3. Exporta los enlaces internos que apuntan a URLs con 3xx y 4xx, y cuenta cuántas páginas de origen están implicadas.
4. Localiza tus diez URLs más importantes y anota a cuántos clics de la portada están.

Qué deberías tener al acabar: una respuesta escrita a cada una de tus tres preguntas iniciales, o una explicación de qué dato te falta para responderlas. Las dos salidas son válidas; quedarse mirando la exportación no.

Logs de servidor: la fuente que no interpreta nada

Search Console te da agregados y muestras. Un rastreador de escritorio te dice lo que él encontró. Los logs del servidor te dicen exactamente qué URL pidió Googlebot, a qué hora, qué le devolviste y cuánto tardaste. Es la única fuente sin intermediarios y, en sitios grandes, cambia por completo el diagnóstico.

Qué pedir y en qué formato

Pide los logs de acceso en bruto, no un panel resumido. Un registro típico incluye dirección IP, fecha y hora, método y ruta, código de estado, bytes, referente y agente de usuario. Necesitas como mínimo ruta completa con parámetros, código de estado, agente de usuario, fecha y hora, e IP. Con menos de eso no se puede trabajar.

Un mes suele ser el mínimo útil; en sitios con catálogos grandes, tres. Si hay una red de distribución de contenidos o un balanceador por delante, asegúrate de que los logs recogen las peticiones que llegan al origen y, si puedes, también las que resuelve la propia red, porque si no verás solo la mitad del rastreo.

Verificar que Googlebot es Googlebot

El agente de usuario se falsifica en un segundo, y una parte apreciable de las visitas que dicen ser Googlebot no lo son. La verificación oficial es una resolución DNS inversa: obtienes el nombre de host a partir de la IP, compruebas que pertenece a los dominios que Google documenta y después resuelves ese nombre de vuelta para confirmar que apunta a la misma IP. Google también publica sus rangos de IP en un archivo que puedes consultar en su documentación.

Qué mirar cuando ya tienes los datos limpios

• Reparto de peticiones por sección: qué proporción se va a fichas, a listados, a facetas, a paginación y a recursos estáticos. Casi siempre aparece una sección que se lleva un tercio del rastreo y no genera nada.
• URLs rastreadas que no deberían existir: parámetros de ordenación, sesiones, filtros combinados, restos de un rediseño antiguo.
• URLs importantes nunca visitadas: cruza la lista del sitemap con las que aparecen en los logs. Lo que no aparece, no se está rastreando.
• Códigos de estado servidos al bot: un volumen alto de 3xx y 4xx es rastreo tirado a la basura.
• Tiempo de respuesta: si las peticiones del bot tardan más de lo normal, es un freno directo al volumen de rastreo.
• Frecuencia por plantilla: cada cuánto vuelve a una ficha, a una categoría, a la portada. Te dice qué considera Google que cambia en tu sitio.

De los logs a las decisiones

El análisis de logs no arregla nada por sí solo: te dice dónde se está tirando el esfuerzo. Las acciones que salen de aquí suelen ser cuatro: eliminar URLs que se generan de más, bloquear secciones que ya no interesa rastrear (siempre después de haberlas desindexado correctamente), acortar cadenas de redirección y mejorar el enlazado interno hacia lo que no se visita.

Ejercicio 5: treinta días de logs

1. Consigue al menos treinta días de logs de acceso en bruto de tu dominio.
2. Filtra las peticiones de Googlebot y verifica con DNS inverso una muestra de diez direcciones IP distintas.
3. Calcula el reparto de peticiones por sección del sitio y ordena de mayor a menor.
4. Cruza las URLs del sitemap con las vistas en logs y saca la lista de las que nunca han sido rastreadas.

Qué deberías tener al acabar: dos hipótesis escritas sobre por qué esas URLs no se visitan y qué cambio concreto probarías primero. Si no consigues los logs, anota quién te los ha negado y por qué: esa también es información del proyecto.

Presupuesto de rastreo: cuándo es tu problema

El presupuesto de rastreo es un problema real en sitios con muchas URLs: comercios electrónicos con facetas, portales con filtros, medios con archivos enormes, marketplaces. En una web de trescientas páginas no es tu cuello de botella, y dedicarle tiempo ahí es distraerse. Google lo dice de forma explícita en su documentación: la mayoría de los sitios no necesita preocuparse por esto.

Las dos piezas del concepto

• Límite de capacidad de rastreo: cuánto puede rastrear Google sin degradar tu servidor. Sube si respondes rápido y de forma estable; baja en cuanto aparecen errores de servidor o tiempos altos.
• Demanda de rastreo: cuánto quiere rastrear, en función de la popularidad de las URLs, de cada cuánto cambian y de si el sitio en conjunto merece atención.

Lo importante es que puedes influir en las dos, pero no se compran. No hay ningún ajuste en Search Console que aumente el presupuesto; lo que hay es dejar de desperdiciarlo.

Dónde se desperdicia

• Facetas y filtros combinables: cuatro filtros con cinco valores generan cientos de URLs equivalentes. Es la primera causa, con diferencia.
• Parámetros de ordenación y de seguimiento, incluidos los identificadores de sesión y las etiquetas de campaña.
• Paginación interminable de listados que no llevan a ningún sitio útil.
• Cadenas de redirección: cada salto es una petición más que no devuelve contenido.
• Páginas de resultados del buscador interno, que pueden generar URLs sin fin.
• Contenido idéntico servido en varias rutas: con y sin barra final, con y sin mayúsculas, en http y en https.

Qué hacer con cada caso

La herramienta correcta depende de si quieres que esa URL exista en el índice o no:

1. No debe existir: que la plantilla no genere el enlace. Lo que no se enlaza no se descubre. Es la solución más limpia y la que menos se usa.
2. Existe pero no debe indexarse: noindex, dejando rastrear hasta que Google lo procese.
3. Existe y es una variante de otra: canonical a la principal. Es una señal, no una orden, así que refuérzala con enlazado interno coherente.
4. Ya está fuera del índice y solo consume rastreo: entonces sí, bloqueo por patrón en el robots.txt.

El orden importa. Bloquear primero en el robots.txt congela la situación: Google deja de poder leer el noindex o el canonical y esas URLs pueden quedarse en el índice indefinidamente.

Lo que sí mueve la aguja

Además de recortar basura: un servidor rápido y estable, porque el tiempo de respuesta es un límite duro; sitemaps limpios con solo URLs indexables y con fechas de modificación honestas; y un enlazado interno que ponga lo importante a pocos clics de la portada. Los sitemaps no aumentan el presupuesto, pero orientan la demanda hacia donde te interesa.

Cómo medirlo

Las estadísticas de rastreo de Search Console te dan solicitudes totales, tamaño de descarga y tiempo medio de respuesta, además del desglose por tipo de archivo, por respuesta y por finalidad. Es la vista rápida y suele bastar para detectar un cambio brusco. Para saber en qué se va el rastreo por sección, necesitas logs: no hay atajo.

Ejercicio 6: un plan en dos fases

1. Cuenta cuántas URLs indexables tiene tu sitio y compáralo con las solicitudes de rastreo diarias de las estadísticas de rastreo.
2. Identifica los tres patrones de URL que más peticiones consumen sin aportar tráfico.
3. Para cada patrón, decide la herramienta correcta (no generar el enlace, noindex, canonical o bloqueo) y justifica por qué.
4. Revisa el tiempo medio de respuesta y anota si hay picos coincidentes con caídas de rastreo.

Qué deberías tener al acabar: un plan de dos fases con el orden correcto, primero desindexar y después bloquear. Con eso cierras el módulo de fundamentos y ya puedes entrar en rendimiento, que es donde el trabajo se vuelve medible semana a semana.