La mayoría de auditorías SEO técnicas son informes superficiales de Screaming Frog disfrazados de estrategia. Alguien lanza un crawl, exporta una hoja con 4.000 filas, marca en rojo lo que queda feo y lo llama auditoría.
No es una auditoría. Es un informe.
Una auditoría SEO técnica de verdad empieza con una pregunta: ¿por qué este sitio no rinde como debería? Y responde mirando señales que las herramientas de rastreo no ven ni de lejos: logs del servidor, datos de rendimiento real por página, flujo de equity a través del enlazado interno y cómo se comporta Googlebot en el sitio de verdad, no cómo supones que se comporta.
Después de 18 años haciendo esto, te lo digo claro: los hallazgos que más impacto tienen salen justo de ahí. No de la lista de 400 meta descriptions que pasan de 160 caracteres.
Esta guía resume el framework completo que uso. No es genérica. Va con detalles que te ahorrarán tiempo o te harán ver problemas que llevas tiempo pasando por alto.
Por qué el SEO técnico es la base
Contenido y enlaces son los dos factores de ranking más citados en SEO. Los dos necesitan una base técnica funcional para aportar algo.
Imagina un sitio con 200 artículos de alta calidad y 500 dominios de referencia. Si Googlebot no puede rastrear el 30% del sitio por unas reglas robots.txt mal montadas, ese contenido no existe para Google. Si los tags canonical están mal implementados en un catálogo de producto, el equity de los enlaces que apuntan a esas páginas se diluye entre URLs duplicadas. Si los Core Web Vitals son lo bastante flojos como para activar las señales de experiencia de página de Google, rankings que deberían estar en posición 3 acaban en posición 8.
El SEO técnico no tiene glamour. Los clientes casi nunca lo piden porque arreglar una cadena de redirects no luce mucho en una reunión. Pero en todas las cuentas que he heredado y que iban por debajo de lo que tocaba, la deuda técnica estaba metiendo mano en el problema. Siempre.
Arregla primero la base técnica. Luego ya construyes encima.
El problema de las auditorías hechas solo con crawlers
Screaming Frog, Sitebulb y herramientas parecidas son imprescindibles. Las uso en todas las auditorías. Pero tienen una limitación de fondo: simulan cómo podría rastrear un crawler tu sitio, no cómo lo rastrea Googlebot en la realidad.
El análisis de logs del servidor te dice lo que Googlebot hizo de verdad. Y la diferencia importa.
Con los logs del servidor puedes responder preguntas que ninguna herramienta de crawl te va a dar:
- ¿Qué páginas visita Googlebot y con qué frecuencia?
- ¿Está gastando su crawl budget en páginas que importan?
- ¿Hay páginas que no reciben ni una visita de Googlebot aunque estén en tu sitemap?
- ¿Existe una diferencia entre las páginas que tú consideras prioritarias y las que Google está rastreando de verdad?
En un cliente del sector financiero, el análisis de logs reveló que Googlebot estaba gastando el 40% del crawl budget en páginas de paginación (/page/2/, /page/3/) y URLs con parámetros generadas por un sistema de filtros. El contenido editorial de más valor se rastreaba poco. Corregir eso tuvo más impacto que cualquier hallazgo típico de una herramienta de crawl.
Para analizar logs puedes usar Screaming Frog Log Analyzer y Splunk cuando los archivos son grandes. Si trabajas con un hosting gestionado que no expone los logs del servidor, ahí tienes una limitación seria que conviene escalar al equipo de infraestructura.
Crawl budget: qué es y cómo auditarlo
El crawl budget es el número de páginas que Googlebot rastrea en tu sitio durante un periodo determinado. En sitios pequeños, de unos pocos miles de páginas o menos, rara vez limita nada. En ecommerce grandes, es uno de los factores que más condicionan que el contenido nuevo se indexe rápido o no.
Google calcula el crawl budget a partir de dos cosas: el límite de velocidad de rastreo, es decir, lo rápido que Googlebot puede rastrear sin tumbar tu servidor, y la demanda de rastreo, o sea, lo populares y recientes que son tus páginas. En ambos frentes puedes influir.
Para auditar el crawl budget necesitas tres fuentes de datos trabajando juntas.
La primera es Google Search Console. Ve a Ajustes > Estadísticas de rastreo. Ahí verás cuántas páginas rastreó Googlebot al día durante los últimos 90 días, qué códigos de respuesta encontró y qué tipos de archivo rastreó. Un sitio donde el 20% de las peticiones de rastreo acaba en 404 está tirando crawl budget a URLs muertas.
La segunda son tus logs del servidor. Cruza qué URLs golpea Googlebot con más frecuencia. Si está gastando presupuesto en URLs de poco valor como navegación facetada, páginas de parámetros o resultados de búsqueda interna, ese presupuesto no está yendo al contenido que sí importa.
La tercera es tu sitemap. El sitemap XML es una señal para Google de lo que tú consideras importante. Si contiene páginas 404, URLs redirigidas o páginas con noindex, le estás mandando señales confusas. Un sitemap limpio, con solo páginas canónicas, indexables y con estado 200, no es opcional.
Los asesinos más habituales del crawl budget que encuentro en ecommerce son estos: navegación facetada, por bastante margen; IDs de sesión añadidos a las URLs; filtros por parámetros sin control canonical; y versiones imprimibles de páginas. Más abajo entro en detalle con la navegación facetada.
Core Web Vitals: la media del sitio no sirve para nada
Los Core Web Vitals de Google son tres métricas que miden experiencia real de usuario: Largest Contentful Paint (LCP), Cumulative Layout Shift (CLS) e Interaction to Next Paint (INP, que sustituyó a FID en marzo de 2024).
Aquí está el error que cometen muchísimos equipos: miran los Core Web Vitals a nivel de dominio y presentan una nota única. Eso no diagnostica nada.
Los Core Web Vitals se evalúan a nivel de grupo de páginas. Las señales de experiencia de página de Google se aplican a patrones de URL concretos, no al sitio entero. Una plantilla de producto con una hero image lenta afecta a todas las fichas de producto. Que la home apruebe CWV no te salva si tus 10.000 páginas de categoría suspenden.
Usa el informe de Core Web Vitals de Google Search Console para ver datos por grupo de páginas. Y usa PageSpeed Insights para probar URLs individuales con datos de campo reales, tomados del Chrome UX Report, junto con los datos de laboratorio.
Qué significa cada métrica en la práctica:
LCP (Largest Contentful Paint): El tiempo que tarda en cargarse el elemento visible más grande. Objetivo: por debajo de 2,5 segundos. Las causas más frecuentes de un LCP malo son hero images sin optimizar, ya sea por formato incorrecto, falta de preload o un CDN lento, recursos que bloquean el renderizado y tiempos de respuesta del servidor altos, con TTFB por encima de 800 ms. En Shopify y WooCommerce, los scripts de terceros cargados en el <head> suelen ser culpables habituales.
CLS (Cumulative Layout Shift): Inestabilidad visual, es decir, elementos que saltan mientras carga la página. Objetivo: por debajo de 0,1. Las causas típicas incluyen imágenes sin atributos explícitos de ancho y alto, contenido inyectado dinámicamente por encima del fold y web fonts que desplazan el layout al cargarse. CLS suele venir de redes publicitarias y banners de consentimiento de cookies que aparecen después del render inicial.
INP (Interaction to Next Paint): Capacidad de respuesta ante la interacción del usuario. Objetivo: por debajo de 200 ms. Es la métrica más nueva y también la más puñetera de arreglar. La causa principal son tareas largas de JavaScript que bloquean el hilo principal. En Shopify, las apps que disparan JavaScript pesado al interactuar suelen ser responsables directas.
Empieza por LCP. Es la métrica con relación más directa con el ranking y la que suele tener fixes más claros.
Implementación de canonicals: errores que escalan muy mal
Los tags canonical le dicen a Google qué versión de una URL consideras la versión principal. Si te equivocas a escala, acabas repartiendo equity entre decenas o cientos de URLs duplicadas.
La checklist del audit de canonicals:
Canonicals autorreferenciales. Toda página indexable debería tener un tag canonical que apunte a sí misma. Si no lo tiene, dejas la decisión en manos de Google, y Google no siempre elige la URL que te conviene.
Canonicals cross-domain. Si sindicas contenido o tienes contenido publicado en varios dominios, los canonical deben apuntar a la fuente original.
Canonicals incoherentes. Si la página A canonicaliza a la página B, pero la página B canonicaliza de vuelta a la A, has creado un bucle canonical. Lo normal es que Google ignore ambas señales.
Canonicals en conflicto con hreflang. Si tienes contenido multilingüe, los tags hreflang y canonical tienen que ser coherentes. Un canonical que apunta desde la versión española de una página a la inglesa le está diciendo a Google que la página en español es un duplicado de la inglesa. Así se rompe una estrategia internacional en dos minutos.
El problema canonical específico de Shopify. Shopify genera dos URLs válidas para cada producto: /products/product-name y /collections/collection-name/products/product-name. Por defecto, canonicaliza la URL de la colección hacia la URL del producto sin colección. En general funciona, pero da problemas cuando un producto aparece en varias colecciones, porque la URL canonical tiene que ser consistente independientemente de cómo entre el usuario. Lo explico mejor en la guía completa de SEO para ecommerce.
Herramienta para auditarlo: haz un crawl con Screaming Frog, exporta el informe de Canonicals y filtra todo canonical que no sea una URL autorreferencial apuntando a una página con estado 200. Cada excepción necesita revisión manual.
Cadenas de redirects y bucles de redirección
Una cadena de redirects aparece cuando la URL A redirige a la URL B, que luego redirige a la URL C. El destino final es correcto, pero el camino gasta crawl budget y pierde equity en cada salto.
PageRank, que es la señal de equity subyacente, pasa a través de redirecciones 301, pero no al 100%. Google no ha confirmado públicamente la tasa exacta de dilución, aunque pruebas de Ahrefs apuntan a una pérdida medible en cada hop. Más importante todavía: si otros sitios enlazan a la URL original y esa URL forma parte de una cadena, el equity que envían da dos saltos antes de llegar a la página viva.
La causa más habitual de las cadenas de redirects es una migración de URLs mal auditada. El sitio se rediseña, se montan redirecciones de antiguo a nuevo. Luego llega otro rediseño y, en vez de actualizar los redirects viejos para que apunten directamente al destino final, se añade otra capa por encima. Y así se va montando el lío.
Cómo encontrarlas: Screaming Frog las marca en su informe de Redirects. Exporta el informe, filtra cadenas de 2 o más saltos y actualiza cada una para que la URL original redirija directamente al destino final.
Los bucles de redirect, donde la URL A redirige a B y B devuelve a A, generan errores y hay que corregirlos de inmediato.
Schema markup: qué schemas importan de verdad
El schema markup es dato estructurado legible por máquinas que ayuda a motores de búsqueda y sistemas de IA a entender tu contenido. No mejora rankings por arte de magia, pero sí habilita rich results como estrellas, precios, FAQs desplegables o breadcrumbs, que pueden aumentar el CTR. Además, cada vez pesa más en la visibilidad en GEO y búsqueda con IA.
La auditoría de schema responde a dos preguntas: qué está implementado y si está bien implementado.
Herramientas de verificación: Google Rich Results Test para páginas individuales, Schema Markup Validator de schema.org para validar sintaxis y el informe de Rich Results de Google Search Console para revisar el estado global del sitio.
Schemas que conviene auditar según el tipo de web:
Para cualquier sitio: Organization en la home, BreadcrumbList en todas las páginas y SiteLinks Searchbox, opcional pero útil en búsquedas de marca.
Para sitios de contenido o blog: Article o BlogPosting con author, datePublished, dateModified y publisher correctamente rellenados, además de FAQPage cuando haya secciones de preguntas frecuentes.
Para ecommerce: Product con name, description, image, sku, offers y aggregateRating; Offer con price, priceCurrency, availability y url; y AggregateRating solo si las reseñas son reales. Inventarse reseñas es una mala idea y además se nota.
Para negocios locales: LocalBusiness con address, telephone, openingHours y geo.
Errores de schema que veo mucho en auditorías: falta priceCurrency en el schema Offer, que Google exige; AggregateRating con menos reseñas de las mínimas para activar rich results; FAQPage donde la respuesta del schema no coincide con el contenido visible; y schema Product sin la propiedad offers, que lo deja prácticamente inútil para resultados de Shopping.
Navegación facetada: el enemigo número uno del crawl budget en ecommerce
La navegación facetada, es decir, el sistema de filtros que deja navegar por color, talla, rango de precio, marca y otros atributos, es el problema de SEO técnico más habitual en ecommerce con catálogos grandes.
El problema es simple: cada combinación de filtros genera una URL nueva. Una categoría con 200 productos, 5 colores, 4 tallas y 3 rangos de precio puede generar teóricamente miles de URLs únicas. La mayoría tienen contenido casi duplicado y poco valor diferencial. Google las rastrea igualmente.
El resultado es previsible: el crawl budget se consume en páginas de filtro de poco valor, las señales canonical se vuelven ambiguas y las páginas de categoría que de verdad quieres posicionar pueden perder fuerza.
La solución no es universal. Depende de qué combinaciones de filtros tengan demanda de búsqueda real. Los filtros por marca muchas veces sí la tienen. Las combinaciones por color o talla, en la mayoría de categorías, casi nunca.
El enfoque estándar:
- Usa
noindexen combinaciones de filtros sin demanda de búsqueda. Así siguen siendo rastreables, pero no entran en el índice. - Añade canonical en las páginas de filtro apuntando a la URL raíz de la categoría.
- Bloquea patrones de parámetros de poco valor mediante
robots.txtcuando no haya intención de búsqueda detrás. - Para combinaciones con demanda real, por ejemplo “zapatillas de running para mujer”, crea landing pages optimizadas en lugar de depender de URLs generadas por filtros.
El enfoque vía robots.txt es bruto, pero rápido. El enfoque canonical es más fino, aunque puede dejar a Googlebot rastreando páginas que nunca va a indexar, y eso también consume presupuesto. En producción, lo normal es que la respuesta correcta sea combinar ambos.
Para una gestión más detallada en ecommerce, mira la guía de SEO para ecommerce.
Distribución del equity en el enlazado interno
Los enlaces internos reparten autoridad por el sitio. Las páginas que reciben más enlaces internos desde páginas fuertes tienden a posicionar mejor, todo lo demás igual. La mayoría de webs distribuyen ese equity por accidente.
Las preguntas que hay que hacerse en la auditoría:
¿Qué páginas están huérfanas? Una página huérfana no recibe ningún enlace interno. Googlebot solo puede encontrarla por sitemap o por un enlace externo. Eso significa que no acumula autoridad interna. Screaming Frog puede detectarlas rastreando el sitio y filtrando las páginas con cero inlinks.
¿Cuál es la profundidad de rastreo de las páginas prioritarias? La profundidad de rastreo es el número de clics desde la home hasta una página concreta. Google la usa como señal aproximada de importancia. Las páginas prioritarias, como servicios principales, categorías top o artículos que más negocio mueven, deberían estar a 2 o 3 clics. Si tu contenido más importante está enterrado a 6 clics, el enlazado interno está fallando.
¿Hacia dónde se está yendo el equity que no debería ir? Los enlaces del footer, la navegación y la sidebar reparten equity hacia donde apuntan. Si tu footer global enlaza a 40 páginas, ese valor sale diluido. Prioriza enlaces contextuales dentro del cuerpo del contenido. Suelen transferir más equity y además son más relevantes a nivel temático.
¿El anchor text es descriptivo y variado? El anchor text de los enlaces internos da señales de relevancia temática. “Haz clic aquí” o “más información” no ayudan a nadie. Usa anchors descriptivos que incluyan la keyword con la que quieres posicionar la página de destino.
Una herramienta práctica: el informe de Links de Screaming Frog te enseña el número de inlinks por página. Ordena de menor a mayor para detectar páginas infravinculadas. Luego cruza eso con tu lista de páginas prioritarias. Cualquier página importante con menos de 5-10 inlinks contextuales desde contenido relacionado debería entrar en la siguiente ronda de mejoras.
Framework de priorización de acciones
Toda auditoría SEO técnica saca más problemas de los que un equipo puede arreglar de golpe. El framework de priorización convierte una lista en un plan.
El sistema es sencillo. Valora cada problema en dos dimensiones:
Impacto: cuánto mejora el rendimiento orgánico si lo corriges. (Alto / Medio / Bajo) Esfuerzo: cuánto tiempo y recursos técnicos exige corregirlo. (Alto / Medio / Bajo)
Y después agrúpalos en cuatro bloques:
Corrige ya (alto impacto / bajo esfuerzo): cadenas de redirects hacia páginas existentes, canonicals ausentes en páginas clave, sitemap XML con URLs redirigidas o 404, robots.txt bloqueando secciones importantes por error, schema ausente en páginas templadas.
Planifica para el próximo sprint (alto impacto / alto esfuerzo): rehacer la navegación facetada, limpieza de una migración con cadenas multi-hop a escala, fixes de Core Web Vitals que requieren tocar el tema o la plantilla, análisis de logs y redistribución del crawl budget.
Hazlo cuando toque (bajo impacto / bajo esfuerzo): optimización de meta descriptions, retoques en title tags, alt text en imágenes de páginas no prioritarias.
Evalúa el ROI (bajo impacto / alto esfuerzo): cambios importantes en el CMS para resolver problemas SEO menores, reestructuraciones hreflang complejas con poco tráfico internacional, implementaciones custom de schema para tipos de página que no generan rich results.
Lo más valioso que debería darte una auditoría es esta priorización. La lista de problemas suele ser bastante previsible. Saber qué tres cosas van a marcar la diferencia en los próximos 90 días es lo que separa una auditoría útil de un informe decorado.
Si necesitas una auditoría SEO profesional sobre tu sitio, el servicio de auditoría SEO cubre todo lo anterior y añade un plan de acción priorizado. Si lo que buscas es acompañamiento continuo y no una auditoría puntual, mira el servicio de consultor SEO.
Referencias útiles
- Google Search Essentials (SEO Starter Guide)
- Creating Helpful, Reliable, People-First Content
- Structured Data Intro
FAQ
¿Qué incluye una auditoría SEO técnica?
Una auditoría SEO técnica completa cubre análisis de crawl budget y logs del servidor, Core Web Vitals a nivel de grupo de páginas, implementación de canonicals, cadenas de redirects, estado del sitemap XML, configuración de robots.txt, validez del schema markup, gestión de navegación facetada en ecommerce y distribución del equity interno. El resultado debería ser una lista de acciones priorizada, no un volcado bruto de incidencias.
¿Cuánto tarda una auditoría SEO técnica? Para un sitio con menos de 10.000 páginas, una auditoría en condiciones suele requerir entre 2 y 4 días de trabajo concentrado. En ecommerce grandes, con más de 100.000 URLs, navegación facetada compleja y análisis de logs, puede irse a 5-10 días. El coste está muy al principio: una vez hecho el diagnóstico, los fixes se convierten en tareas concretas repartibles por sprint.
¿En qué se diferencia una auditoría SEO técnica de una auditoría SEO general? La auditoría SEO técnica se centra en cómo está construido el sitio y cómo interactúan con él los motores de búsqueda: rastreabilidad, indexación, velocidad, datos estructurados, canonicals y arquitectura. Una auditoría SEO más amplia también entra en calidad del contenido, targeting de keywords y perfil de enlaces entrantes. Son problemas distintos. Normalmente necesitas ambas.
¿Los sitios pequeños necesitan una auditoría SEO técnica? Sí, pero con un alcance distinto. Los sitios pequeños, por debajo de 500 páginas, rara vez tienen problemas serios de crawl budget o navegación facetada. Pero sí sufren canonicals mal puestos, schema ausente, Core Web Vitals flojos y carencias de enlazado interno que afectan al ranking. En un sitio pequeño la auditoría puede llevar medio día en vez de varios, pero saltársela sigue siendo una mala idea.
¿Qué herramientas necesito para hacer una auditoría SEO técnica? Kit mínimo: Google Search Console para estadísticas de rastreo, cobertura, Core Web Vitals y rich results; Screaming Frog SEO Spider para crawl analysis, redirects, canonicals y enlazado interno; PageSpeed Insights o Lighthouse para los datos de laboratorio; y Rich Results Test para validar schema. Para logs del servidor, Screaming Frog Log Analyzer cubre la mayoría de casos. A escala enterprise, Botify u Oncrawl ofrecen análisis más avanzados.
¿Cada cuánto deberías hacer una auditoría SEO técnica? En sitios activos, que publican a menudo o tocan plantillas con frecuencia, una revisión ligera mensual con crawler y una auditoría completa cada 6 meses es una cadencia razonable. Si hay migración, rediseño, cambio de CMS o una reestructuración fuerte de URLs, una auditoría completa antes y después del cambio no se negocia.
¿Qué es el crawl budget y por qué importa? Crawl budget es el número de páginas que Googlebot rastrea en tu sitio durante un periodo concreto. En la mayoría de sitios pequeños no preocupa demasiado. En ecommerce grandes, con decenas de miles de URLs, la capacidad de rastreo de Googlebot es finita. Si se la comen páginas de parámetros, paginación o combinaciones de filtros de poco valor, el contenido importante puede tardar más en indexarse. Donde más importa es en sitios con 10.000+ páginas, publicación frecuente y estructuras de URL complejas.
Sobre el autor Luciano Bonanno es consultor SEO y Growth independiente con 18 años de experiencia. Fundador de SameAPI y DeLeak.co. Reserva una llamada estratégica →