Log de rastreo SEO en eCommerce: guía + plantilla

Si en los primeros 3 segundos no te queda claro por qué deberías mirar logs: porque el rastreo es el “combustible” del SEO técnico. Puedes tener el mejor enlazado interno del mundo o una arquitectura impecable, pero si Googlebot se pasa el día entrando en combinaciones infinitas de filtros y parámetros, tu tienda puede quedarse sin rastreo suficiente para lo que de verdad importa: categorías, productos y landings que convierten. A fecha de 18 de marzo de 2026, además, esto impacta no solo en rankings clásicos, sino también en la visibilidad en resultados con IA (resúmenes, respuestas y descubrimiento), donde la consistencia de indexación y el acceso a URLs canónicas es clave.

En esta guía vas a aprender a conseguir logs (hosting/CDN y particularidades de plataformas), a usar una plantilla en Google Sheets, a detectar patrones típicos de eCommerce (facetas, paginación, 404, duplicados) y a convertir hallazgos en un plan de acción priorizado. Si quieres que lo revisemos contigo en un marco completo, en servicios de SEO eCommerce lo integramos dentro de auditorías técnicas y automatizaciones.

1. Qué es el análisis de logs y cuándo usarlo en eCommerce

El análisis de logs SEO consiste en estudiar los registros de acceso (log files) del servidor web o de la capa que entrega contenido (CDN/WAF/proxy) para entender cómo rastrean los bots tu sitio. Un log, en esencia, es una línea por solicitud: fecha/hora, IP, método, URL, código de estado, user-agent, bytes, referer, etc. Con eso puedes responder preguntas que otras fuentes no resuelven bien:

• ¿Qué URLs rastrea Googlebot realmente? No lo que aparece en un crawler o en Search Console, sino lo que pide al servidor.
• ¿Cuánto rastreo se está yendo a parámetros/facetas/paginación? En eCommerce, suele ser el principal “agujero negro”.
• ¿Qué errores de servidor y 404 ve Google? Y si son persistentes o puntuales.
• ¿Rastrea más las URLs que te interesan? (categorías top, productos con stock, landings de marca) o se dispersa.

¿Cuándo merece la pena? En eCommerce, casi siempre hay señales claras:

• Catálogo grande (miles o millones de URLs) o crecimiento rápido.
• Indexación errática: muchas URLs “Descubiertas: actualmente sin indexar” o “Rastreada: actualmente sin indexar” (no uses esto como “prueba” única, úsalo como disparador).
• Cambios en facetas, filtros, paginación, búsqueda interna o rediseños.
• Rendimiento irregular del servidor (picos de 5xx) o CDN mal configurada.
• Discrepancia entre lo que cree el equipo (sitemap, enlazado) y lo que hace Googlebot.

Importante: el análisis de logs no sustituye una auditoría técnica; la complementa. La auditoría te dice “qué debería pasar” (canónicas, noindex, robots, arquitectura). Los logs te dicen “qué está pasando”. En nuestro método solemos cruzar ambas capas para priorizar: primero arreglamos lo que está consumiendo rastreo y perjudicando indexación, luego refinamos enlazado y señales.

También es una pieza útil para posicionar en entornos con IA: si un sistema necesita recuperar contenido consistente y canónico, pero el rastreo se va a URLs duplicadas, es más probable que tu información “buena” llegue tarde, incompleta o fragmentada.

2. Cómo conseguir los logs (hosting, CDN, Shopify, PrestaShop)

La forma de obtener logs depende de dónde se “termina” la petición web. En muchas tiendas modernas, el tráfico pasa por CDN/WAF (Cloudflare, Akamai, Fastly, etc.) antes de llegar al servidor. Si puedes, prioriza logs del punto más cercano a la entrega real al bot (a menudo el CDN), porque reflejan solicitudes que quizá ni alcanzan tu servidor si hay caché, bloqueos o desafíos.

Opción A: logs del servidor (Apache/Nginx). En hosting propio o VPS es lo más directo. Pide o extrae:

• Access logs (solicitudes) y, si hay problemas, error logs.
• Formato recomendado: combined (incluye user-agent y referer).
• Rango: mínimo 7 días; ideal 30 días si el sitio tiene estacionalidad o gran catálogo.

Opción B: logs del CDN/WAF. Si la tienda está detrás de una CDN, pide/exporta los campos: timestamp, URL/URI, status, user-agent, método, bytes, cache-status, edge location. Esto te permite ver: qué se sirve desde caché, si hay bloqueos y si los bots están recibiendo respuestas inconsistentes.

Shopify: en Shopify “puro” no tienes acceso a logs del servidor como en un VPS. Aquí la práctica habitual es:

• Usar registros del CDN/WAF si tienes una capa externa delante (por ejemplo, si estás con una solución enterprise o proxy propio).
• Apoyarte en señales indirectas (servidor de app externo, endpoints propios, logs de buscador interno si lo gestionas fuera, etc.) y, sobre todo, en auditoría de arquitectura para limitar facetas. Aun así, el análisis de logs puede ser parcial.

PrestaShop / WooCommerce: normalmente sí puedes acceder a logs del servidor o del hosting. Si estás en hosting gestionado, solicita al proveedor:

• Access logs de Nginx/Apache (formato combined), comprimidos por día.
• Confirmación de zona horaria y rotación.
• Si hay CDN, también la exportación del edge.

Recomendación técnica: asegura que los logs incluyan user-agent completo. Sin eso, segmentar por bot (Googlebot, Bingbot, etc.) es mucho menos fiable. Y si vas a automatizar en n8n o scripts, pide un formato estable (CSV o texto con separador consistente) para evitar roturas.

Si necesitas una revisión de la infraestructura (caché, CDN, rendimiento, tracking) y cómo impacta al rastreo, revisa optimización técnica de webs, porque muchas veces el “problema de crawl budget” es en realidad un problema de respuestas, caché o arquitectura de URLs.

3. Plantilla en Sheets: métricas clave y segmentación por bots

Una plantilla efectiva en Google Sheets no pretende reemplazar un “log file analyzer” avanzado, sino darte un análisis rápido y accionable. La clave es normalizar datos, etiquetar tipos de URL y segmentar por bot. Estructura recomendada:

• Hoja 1: Raw: pega/importa logs con columnas: datetime, URL, status, user-agent, bytes, referer, IP (si la tienes), cache-status (si hay CDN).
• Hoja 2: Normalización: extrae path, querystring, host, y crea una URL “limpia” (sin parámetros) para agrupar.
• Hoja 3: Clasificación: etiqueta cada fila por tipo de URL (producto, categoría, paginación, faceta/param, búsqueda interna, cuenta/carrito, recursos estáticos).
• Hoja 4: Resumen: tablas dinámicas por bot, status, tipo de URL y día.

Segmentación por bots (mínimo viable): crea una columna “Bot” con reglas por user-agent. Ejemplos:

• Googlebot: contiene “Googlebot” (y si quieres separar: Smartphone/desktop).
• Bingbot: contiene “bingbot”.
• Otros: “DuckDuckBot”, “YandexBot”, etc.
• Unknown/Other: el resto.

Métricas clave que deberías calcular en el resumen:

• Total hits por bot y por día (tendencias).
• Distribución por status: 200, 301/302, 404, 410, 5xx.
• % de hits a parámetros (URLs con “?”) vs URLs limpias.
• Top URLs por hits (y si son “buenas” o “ruido”).
• Frecuencia de rastreo por plantilla: producto/categoría/paginación.

Cómo etiquetar tipos de URL sin herramientas: usa patrones de path. Por ejemplo (adáptalo a tu CMS):

• Producto: /producto/, /p/ o patrón con SKU.
• Categoría: /categoria/ o árbol de categorías.
• Paginación: ?page=, /page/.
• Facetas/filtros: parámetros como color=, talla=, precio=, sort=.
• Búsqueda interna: /search, ?q=.

Con esto, en 30–60 minutos puedes ver un mapa claro de consumo de rastreo. Si quieres llevarlo a automatización (ingesta diaria, alertas por 5xx o picos de parámetros), en SEOAGIL solemos montarlo con flujos que consolidan logs y envían alertas operativas.

4. Detecta problemas típicos: facetas, paginación, 404 y duplicados

En eCommerce, el análisis de logs casi siempre revela los mismos “culpables”, pero con matices según plataforma y catálogo. La idea no es “bloquear todo”, sino controlar la exploración para que Google invierta recursos donde hay negocio.

Facetas y filtros (parámetros): si ves que una parte grande de hits de Googlebot van a URLs con “?” (o combinaciones de filtros), tienes un problema de control de espacio de URLs. Señales típicas en logs:

• Muchas URLs con varios parámetros combinados (color+talla+precio+ordenación).
• Rastreo recurrente de URLs con sort= u ordenaciones que no aportan valor SEO.
• Patrones de rastreo “infinitos” (fácil de ver si el top 100 de URLs son parámetros).

Paginación: no es “mala” por defecto; en categorías grandes es inevitable. El problema aparece cuando:

• Googlebot dedica demasiado a páginas profundas que no aportan (page=50, 80…).
• Hay paginación + facetas multiplicando URLs.
• Las páginas paginadas devuelven contenido muy similar y poca diferenciación.

404/410: en eCommerce suelen venir de:

• Productos descatalogados sin redirección o sin alternativa (o con redirecciones en cadena).
• Enlaces internos antiguos (menús, módulos, filtros) o enlaces desde sitios externos.
• Recursos estáticos rotos (imágenes, JS) que también consumen rastreo.

Duplicados y canónicas inconsistentes: los logs no te dicen directamente la canónica, pero sí te revelan el síntoma: Googlebot invierte rastreo en variantes que no deberían existir. Ejemplos:

• URLs con y sin barra final, con mayúsculas, o con parámetros de tracking.
• Versiones HTTP/HTTPS o www/no-www mal consolidadas (normalmente lo verás como 301 frecuentes).
• Rastreo de URLs de búsqueda interna (que suele ser ruido y puede generar thin content).

Errores comunes al interpretar logs (importante):

• Confundir “hits” con “indexación”: que Googlebot rastree no implica que indexe.
• No separar bots reales de falsos: sin validación por IP/DNS puedes tener user-agents falsificados. Para un análisis práctico, empieza por patrones claros, pero si vas a tomar decisiones drásticas (bloqueos), valida.
• Analizar pocos días: un fin de semana o un pico de campañas puede sesgar. Ideal 30 días en tiendas grandes.
• Bloquear parámetros “a ciegas”: algunos parámetros son funcionales para variantes, stock por tienda o paginación. Primero clasifica y mide.

5. Plan de acción: reglas, enlazado interno y priorización de URLs

El valor del análisis de logs es convertir hallazgos en cambios que mejoren rastreo, indexación y, en última instancia, ingresos. Prioriza así: 1) evitar desperdicio, 2) asegurar acceso a lo importante, 3) consolidar señales.

Paso 1: reduce desperdicio en facetas y parámetros. Acciones típicas (elige según tu caso):

• Robots.txt: bloquear patrones de parámetros que no aportan (por ejemplo, ordenaciones). Ojo: bloquear no elimina URLs ya indexadas; solo impide rastreo.
• Enlaces internos: evita enlazar a combinaciones infinitas de filtros. Si el módulo de filtros crea enlaces crawlables, es un acelerador del problema.
• Canónicas: define canónica a la versión “limpia” cuando la faceta no deba indexar.
• Noindex (cuando aplique): para páginas que deben ser accesibles al usuario pero no indexables (p. ej., búsquedas internas). Asegura que no bloqueas el rastreo si necesitas que Google vea el noindex.

Paso 2: mejora el rastreo de URLs que importan:

• Sitemaps: asegúrate de que incluyen solo URLs indexables y canónicas (productos en stock si tu estrategia lo exige, categorías prioritarias). Aunque los sitemaps no “obligan” a rastrear, ayudan a orientar.
• Enlazado interno: sube la accesibilidad a categorías y productos estratégicos (top ventas, margen alto, long tail relevante). Si en logs ves que Googlebot apenas llega a ciertos productos, suele ser un problema de profundidad o enlaces.
• Performance: si hay 5xx, timeouts o respuestas lentas, Google reduce el ritmo. Revisa servidor, caché y endpoints críticos.

Paso 3: arregla errores que “drenan” crawl budget:

• 404 persistentes: redirecciona solo cuando tenga sentido (producto a categoría equivalente o reemplazo real). Evita redirecciones masivas a home.
• 301 en cadena: simplifica rutas para que Google llegue al 200 final con el mínimo salto.
• URLs duplicadas: fuerza consistencia con redirecciones y normalización (www/no-www, slash, mayúsculas, parámetros de tracking).

Checklist práctica (para ejecutar en 48–72h):

• Extraer 7–30 días de logs del servidor o CDN.
• Segmentar por bot (mínimo: Googlebot vs resto).
• Calcular % de hits en URLs con parámetros.
• Listar top 100 URLs por hits y etiquetar “útil” vs “ruido”.
• Revisar 404 y 5xx por volumen y repetición.
• Identificar patrones de facetas/ordenación a controlar.
• Proponer cambios: robots/canónicas/noindex/enlazado/sitemaps.
• Repetir medición a los 7 y 21 días para validar impacto.

Si quieres que esto se convierta en un sistema continuo (alertas, priorización automática de patrones, reporting), encaja muy bien con una consultoría SEO orientada a automatización y operación, no solo a “auditar y entregar un PDF”.

6. Conclusión: checklist final y siguiente paso (auditoría técnica)

El análisis de logs es de esas prácticas que, una vez la aplicas en eCommerce, se vuelve difícil de abandonar: te da una visión objetiva del rastreo. En marzo de 2026, con catálogos más dinámicos, más capas (CDN, apps, scripts) y más presión por aparecer tanto en resultados tradicionales como en entornos de IA, controlar el rastreo no es “opcional”: es parte de la salud del canal orgánico.

Checklist final (antes de tocar nada):

• ¿Tienes logs completos? (user-agent, status, URL, fecha/hora) y rango suficiente (ideal 30 días).
• ¿Has separado Googlebot del resto? y validado que el patrón de UA es consistente.
• ¿Sabes qué porcentaje del rastreo se va a parámetros? y qué parámetros son los principales responsables.
• ¿Has listado 404/5xx por repetición? para priorizar los que más consumen.
• ¿Tienes definida tu lista de URLs “dinero”? (categorías y productos clave) para comprobar si reciben rastreo suficiente.
• ¿Tienes un plan de cambios medibles? (qué cambias, por qué, y cómo validar en logs en 7–21 días).

Siguiente paso recomendado: convertir los insights en una auditoría técnica accionable (arquitectura de facetas, canónicas, enlazado, sitemaps, performance, tracking). Si no sabes por dónde empezar, en la sección de contacto podemos revisar tu caso y decidir si conviene un sprint de control de rastreo o una auditoría completa con implementación.

Preguntas frecuentes

¿El análisis de logs sustituye a Search Console o a un crawler?

No. Search Console te da señales de indexación y cobertura; un crawler te da una fotografía de enlaces y estado “desde fuera”. Los logs te dicen lo que pasa en el servidor: qué rastrea Googlebot realmente. Lo potente es combinarlos.

¿Cuántos días de logs necesito para un eCommerce?

Como mínimo 7 días para detectar patrones evidentes (404, parámetros, 5xx). En tiendas con mucho catálogo o estacionalidad, 30 días suele dar una lectura más estable. Si hay campañas o cambios recientes, amplía el rango para comparar “antes vs después”.

¿Si bloqueo parámetros en robots.txt, se arregla el crawl budget?

Puede reducir el rastreo de esos patrones, pero no siempre es la solución completa. Si esos parámetros siguen muy enlazados internamente, estás creando fricción. Normalmente se combina con control de enlazado, canónicas coherentes y, cuando aplica, noindex para páginas funcionales.

¿Qué hago con productos descatalogados que aparecen mucho en logs con 404?

Prioriza por volumen (los 404 más rastreados). Si hay sustituto o categoría equivalente, redirige a una alternativa real. Si no existe reemplazo y el producto no debe volver, un 410 puede ser apropiado. Evita redirigir todo a la home.

¿Puedo hacer esto en Shopify sin acceso a logs?

Depende de tu stack. Shopify no suele exponer logs de servidor. Si tienes CDN/WAF propio delante, ahí sí puedes obtenerlos. Si no, puedes trabajar el control de facetas y arquitectura con auditoría técnica, y usar señales indirectas para validar cambios.