Auditoría técnica de SEO: rastreo, indexación, arquitectura y Core Web Vitals

La mayoría de las "auditorías técnicas de SEO" terminan siendo PDFs de 200 páginas archivados en una carpeta de Google Drive que nadie abre. Ingeniería los ignora porque se leen como artículos académicos: inventarios de problemas sin triaje, sin plantillas de tickets y sin estimaciones de tráfico vinculadas a las soluciones.

Esta es la versión para ICs. Cinco áreas de enfoque, diagnósticos con nombre y una cola de tickets de desarrollo que sus ingenieros realmente tomarán en su próximo sprint. El valor de la auditoría no está en el informe. Está en el PR fusionado.

Si sale de una auditoría trimestral con una hoja de cálculo de 47 pestañas pero sin commits, ejecutó un proyecto de investigación, no una auditoría.

El marco de auditoría de 5 áreas

Toda auditoría técnica que realizo cubre las mismas cinco áreas, en este orden, porque las dependencias fluyen hacia abajo: no tiene sentido optimizar los CWV en páginas que Google no puede rastrear, ni corregir el schema en páginas que no están indexadas. Trabaje el funnel.

1. Rastreabilidad
2. Cobertura de indexación
3. Arquitectura y enlazado interno
4. Core Web Vitals
5. Datos estructurados

Puede completar el primer análisis en dos días concentrados para un sitio con menos de 50.000 URLs. Para sitios más grandes, planifique una semana y apoye más en el muestreo de registros.

1. Rastreabilidad

Herramientas: Screaming Frog o Sitebulb para el rastreo completo, registros del servidor para lo que Googlebot realmente obtiene, verificador de robots.txt en GSC.

Comience con robots.txt. Léalo línea por línea. Luego verifique qué está bloqueado a nivel de directorio frente al nivel de patrón. Los errores clásicos que veo al menos una vez por trimestre:

• Reglas de staging filtradas a producción. Alguien copia Disallow: / del staging al robots.txt de producción durante un despliegue. Todo el sitio queda invisible en 48 horas. La corrección son dos caracteres. El daño son seis semanas.
• Rutas /api/ bloqueadas accidentalmente cuando sirven contenido hidratado. Algunas aplicaciones de Next.js y Nuxt hacen solicitudes a /api/... para datos de ISR o SSR. Si esos endpoints están bloqueados, Googlebot ve páginas a medio renderizar en el segundo paso.
• CSS y JS bloqueados. Sigue ocurriendo. Googlebot necesita renderizar la página. Si no puede cargar su hoja de estilos, las comprobaciones de compatibilidad móvil fallan y los posicionamientos caen.
• Bloqueo en la navegación por facetas que es también donde vive el 60% del tráfico de cola larga. Frecuente en comercio electrónico. Bloquee las URLs de parámetros en robots.txt y también habrá bloqueado las señales canónicas que las habrían consolidado.

Tras el robots.txt, ejecute un rastreo completo con Screaming Frog con el renderizado de JavaScript activado. Compare el HTML renderizado con el HTML en bruto. Si la versión renderizada tiene 3.000 palabras más que la versión en bruto, tiene un problema de renderizado de JS. (Más sobre esto a continuación.)

Luego muestree sus registros del servidor. Dos semanas de registros de acceso filtrados por los agentes de usuario de Googlebot. Agrupe por código de estado y patrón de URL. Busque:

• Errores 5xx que llegan a Googlebot (el servidor no puede mantener el ritmo de rastreo)
• Soft 404s (estado 200 con contenido de "página no encontrada")
• Trampas de rastreo (combinaciones infinitas de parámetros en la navegación por facetas, widgets de calendario que llegan al año 3024, ID de sesión en las URLs)

El presupuesto de rastreo solo importa en sitios con más de 100.000 URLs. Si tiene un sitio SaaS con 800 páginas, deje de preocuparse por el presupuesto de rastreo y preocúpese por qué 12 de esas 800 páginas generan el 90% del tráfico orgánico.

2. Cobertura de indexación

Herramientas: Informe de Páginas de GSC (antes Cobertura de índice), Screaming Frog comparando páginas rastreadas con páginas indexadas.

Abra el informe de Páginas de GSC. Filtre por "No indexadas". Lea cada razón de estado. Las dos que generan más errores de regresión:

• "Descubierta, actualmente no indexada." Google encontró la URL pero no la ha obtenido. Generalmente significa que la prioridad de rastreo es baja (contenido delgado, pocos enlaces internos) o que el servidor es lento.
• "Rastreada, actualmente no indexada." Google la obtuvo y decidió no indexarla. Esta es una señal de calidad. Contenido delgado, casi duplicados y páginas que Google considera de bajo valor caen aquí. Corregir esto es un problema de contenido, no técnico. No abra tickets al equipo de desarrollo por "Rastreada, no indexada".

Y los clásicos:

• Noindex en páginas importantes. El error canónico. Alguien añade <meta name="robots" content="noindex"> a un archivo de plantilla usado por todo el directorio /blog/ y el tráfico colapsa en 30 días. He visto esto ocurrir cuando un desarrollador estaba probando un único artículo y olvidó revertir el cambio en la plantilla. Busque siempre noindex en el código fuente durante una auditoría. Sin excepciones.
• Desajustes de canonical. La página A tiene <link rel="canonical" href="page-b">, la página B tiene <link rel="canonical" href="page-a">. Google elige una e ignora la otra, pero a cara o cruz. La corrección: cada página se canonicaliza a sí misma salvo que tenga una razón deliberada de consolidación.
• Gestión de parámetros. Parámetros UTM, ID de sesión, criterios de ordenación, combinaciones de filtros. Cada variante es una URL separada para Google a menos que la canonicalice. Regla predeterminada: toda URL con parámetros se canonicaliza a la URL base limpia. Solo haga excepciones para parámetros que cambien el contenido de forma significativa (como variantes de producto).
• Errores de hreflang. Si gestiona un sitio en varios idiomas, los errores de etiqueta de retorno en hreflang se propagan en cascada. El informe de Segmentación internacional de GSC sigue mostrando estos errores.

Verificación de cordura: busque site:sudominio.com en Google. El número que devuelve debería aproximarse al número de páginas indexadas en GSC (dentro del 20%). Si site: muestra 12.000 y GSC muestra 4.000, algo falla, y la brecha suele deberse a URLs con parámetros que Google indexó antes de que usted las canonicalizara.

3. Arquitectura y enlazado interno

Herramientas: Sitebulb (el mejor para visualizar la profundidad del sitio), informe de profundidad de rastreo de Screaming Frog.

Tres diagnósticos, ordenados por frecuencia con la que los encuentro en auditorías:

Profundidad desde la página de inicio. Cualquier página a más de cuatro clics de la página de inicio es una señal de alerta. Ejecute un rastreo con Screaming Frog, ordene por profundidad de rastreo de forma descendente. Las páginas a profundidad 6 o más suelen ser huérfanas o están varadas por una navegación deficiente. Si su página de producto de mayor ingresos está a profundidad 5, tiene un error de arquitectura, no un error de contenido.

Páginas huérfanas. Páginas sin ningún enlace interno de entrada. Sitebulb tiene un informe dedicado. Causas habituales: páginas de destino antiguas de una campaña, artículos del blog que el equipo editorial olvidó enlazar desde algún lugar, páginas de producto lanzadas sin actualizar la navegación. Enlácelas desde un hub relevante o aplíqueles noindex. No las deje languidecer.

Distribución del enlazado interno. Ejecute el conteo de enlaces internos por URL de Screaming Frog. Trace la distribución. Busque la cola larga de páginas con 0 a 2 enlaces internos. Esas páginas tendrán dificultades para posicionar sin importar qué tan bueno sea el contenido. La estructura hub-and-spoke (página pilar con un clúster de artículos relacionados) es la solución más limpia: cada artículo del clúster enlaza al pilar, y el pilar enlaza de vuelta a todos los artículos del clúster.

Trampas de navegación por facetas. Si trabaja en comercio electrónico o marketplace, la navegación por facetas puede generar millones de combinaciones de URLs. El árbol de decisiones:

• Filtros que cambian el contenido de forma significativa (categoría, marca): indexables, canónicos a sí mismos
• Filtros que solo ordenan o paginan: noindex o canonical a la categoría base
• Filtros combinados (categoría + marca + precio + talla): bloqueados en robots.txt o use AJAX para que no generen URLs rastreables

Migas de pan. Cada página de contenido debería tener un componente de migas de pan visible, marcado con schema BreadcrumbList. Las migas de pan ayudan a los usuarios a orientarse, dan a Google una señal estructural adicional y consiguen la visualización de migas de pan en los SERPs.

4. Core Web Vitals

Herramientas: PageSpeed Insights para datos de laboratorio y de campo, Lighthouse para pruebas de laboratorio reproducibles, panel de rendimiento de Chrome DevTools para el diagnóstico, informe de Core Web Vitals de GSC para el monitoreo.

Los umbrales importan. Memorícelos:

Mida siempre con datos de campo (CrUX, los números de usuarios reales en PageSpeed Insights y GSC), no de laboratorio. Los datos de laboratorio le cuentan una historia; los datos de campo le dicen la verdad. El laboratorio puede estar pasando mientras CrUX está fallando, porque los usuarios reales utilizan redes más lentas y dispositivos más antiguos.

Organice las correcciones por niveles. Cada métrica tiene una escalera clara:

Correcciones de LCP (por orden de esfuerzo frente a impacto):

Correcciones de INP:

Correcciones de CLS:

Ejecute PageSpeed Insights en sus 10 plantillas principales (página de inicio, artículo de blog, categoría, producto, precios, etc.), no en URLs individuales. Las plantillas son donde implementa correcciones una sola vez y se propagan a todo el sitio.

5. Datos estructurados

Herramientas: informe de Resultados enriquecidos de GSC, validador de schema.org, extracción de datos estructurados de Screaming Frog.

Verificación de cobertura. Cada tipo de contenido debería tener su schema correspondiente:

• Artículos: Article o BlogPosting
• Páginas de producto: Product con Offer
• Páginas de preguntas frecuentes: FAQPage
• Organización (página de inicio y pie de página): Organization
• Migas de pan (todas las páginas): BreadcrumbList
• Contenido de instrucciones: HowTo

Ejecute Screaming Frog con la extracción de datos estructurados activada. Filtre por URLs con errores o tipos faltantes. Compárelos con el informe de Resultados enriquecidos de GSC. Ese es la fuente de verdad sobre lo que Google valida.

El enfoque de AEO (optimización para motores de respuesta) importa más cada trimestre. Los sistemas de búsqueda potenciados por LLMs se apoyan fuertemente en los datos estructurados al decidir qué contenido citar. Una página de preguntas frecuentes con schema FAQPage válido y pares de preguntas y respuestas limpios es citada por ChatGPT, Perplexity y los AI Overviews de Google con mucha más consistencia que el mismo contenido sin schema. El schema ya no es solo para los resultados enriquecidos. Es cómo las máquinas deciden de qué trata su página.

La realidad del renderizado de JS

Si su sitio es una SPA construida con React, Vue, Svelte o Angular sin SSR o SSG, está jugando en modo difícil.

Googlebot hace un renderizado en dos pasos. Primer paso: ve su respuesta HTML inicial. Para una SPA sin renderizar, eso es prácticamente un <div id="root"></div> vacío con una etiqueta de script. Segundo paso: horas o semanas después, cuando la cola de renderizado de Google tiene capacidad, vuelve a obtener la página y ejecuta el JS. El contenido se indexa, eventualmente.

El diagnóstico de "página en blanco en Screaming Frog": ejecute Screaming Frog con el renderizado de JS desactivado. Si sus páginas devuelven 200 OK con un <body> vacío, eso es lo que Googlebot ve en el primer paso. Ahora ejecute con el renderizado de JS activado. Si el contenido aparece, Google llegará allí eventualmente. Si no aparece, tiene un error más profundo (muro de autenticación, hidratación rota, error de JS que bloquea el renderizado).

Cuándo importa esto:

• Contenido de noticias y tendencias. Si depende de que Googlebot indexe en menos de 24 horas, el retraso del segundo paso lo perjudica. SSR o SSG, sin excepciones.
• Catálogos grandes. Un sitio de comercio electrónico con 50.000 productos y renderizado del lado del cliente verá cómo el presupuesto de rastreo se consume en la cola de renderizado. Google decide qué páginas merecen el segundo paso.
• Páginas con autenticación obligatoria. Si su lógica de hidratación redirige a usuarios no autenticados (que es lo que Googlebot es), Google ve una redirección, no su contenido.

El árbol de decisiones:

• Si es un sitio de contenido: SSG (Next.js, Astro, Eleventy)
• Si es una aplicación de producto: SSR para las páginas de marketing, CSR para la propia aplicación
• Si migrar es demasiado costoso: prerenderizado (Prerender.io, Rendertron) como solución temporal

Solicite al equipo de ingeniería que registre el encabezado User-Agent en los fallos de renderizado. Si ve Googlebot en esos registros, tiene pruebas para llevar a una sesión de planificación del sprint.

Convertir los hallazgos en tickets de desarrollo

Aquí es donde mueren la mayoría de las auditorías. Los hallazgos son reales. Los tickets nunca se redactan. Ingeniería escoge las tareas más fáciles del backlog porque nadie vinculó el impacto en el negocio a su auditoría.

El entregable es una cola de tickets priorizada. Mi distribución estándar para una auditoría trimestral:

• 3 P0s (problemas que bloquean la indexación). El sitio no puede posicionar si no se corrigen. Ejemplos: noindex en páginas importantes, robots.txt que bloquea directorios indexables, etiquetas canónicas que apuntan a 404s.
• 8 P1s (fallos de Core Web Vitals y problemas de arquitectura). Ejemplos: LCP > 4s en la plantilla principal, sin enlaces internos a las páginas de ingresos, navegación por facetas generando trampas de rastreo.
• 20 P2s: brechas de schema, limpieza de hreflang, reescritura de metadescripciones, texto alternativo de imágenes, mejoras menores de arquitectura.

Cada ticket necesita los mismos campos:

Título: [SEO P0] Etiqueta meta noindex en la plantilla /blog/*

Patrón de URL: Todas las URLs que coincidan con /blog/*
Reproducción:
  1. Visitar https://example.com/blog/cualquier-articulo
  2. Ver el código fuente
  3. Ver <meta name="robots" content="noindex"> en <head>
Esperado: la etiqueta noindex no debería estar presente en los artículos de blog indexables
Evidencia: captura de pantalla del código fuente, informe de Páginas de GSC que muestra 247 URLs
  con estado "Excluidas por la etiqueta 'noindex'"
Impacto de tráfico estimado: 247 URLs actualmente excluidas. Las 20 principales estaban
  en posiciones 4-15 antes de que se añadiera el noindex (datos de Ahrefs).
  Recuperación estimada: 8.000-12.000 visitas orgánicas mensuales en los 60 días
  posteriores a la corrección y la reindexación.
Criterio de aceptación: el archivo de plantilla ya no renderiza la etiqueta noindex para /blog/*.
  El recuento de "Excluidas por noindex" en GSC disminuye en 240 o más.

Ingeniería tomará tickets que se lean así. No tomará tickets que digan "Corregir problemas de indexación en el blog".

La cadencia de auditoría

Las auditorías profundas trimestrales cubren las cinco áreas. Dos días de trabajo concentrado, más una semana para redactar los tickets y acompañarlos a través de la planificación del sprint. Cada trimestre.

Verificación mensual de la cobertura de indexación. Abra el informe de Páginas de GSC el primer lunes de cada mes. Compárelo con la instantánea del mes anterior. Investigue cualquier categoría de "No indexadas" que haya crecido más del 10%.

Revisión semanal de regresiones de CWV. Informe de Core Web Vitals de GSC. Cualquier plantilla que pase de "Bueno" a "Necesita mejora" se investiga dentro de esa misma semana. Detectar una regresión de CWV en 1 semana cuesta 1 hora de trabajo. Detectarla 8 semanas después de un lanzamiento cuesta varios sprints de excavación.

Muestreo de registros del servidor: trimestral es suficiente para la mayoría de los sitios, mensual para sitios con más de 500.000 URLs.

La auditoría no es un entregable único. Es una cadencia operativa. La primera es más laboriosa porque está estableciendo las líneas de base. Para el tercer trimestre, la mayor parte del tiempo se destina a las revisiones de regresión y al triaje de nuevos problemas, no a reauditorías completas.

Implemente correcciones, no hallazgos. La auditoría solo vale lo que valen los PRs fusionados.

Más recursos

• Lista de verificación de SEO on-page para páginas pilar
• Estrategia de enlazado interno para B2B SaaS
• Schema markup para B2B SaaS
• Flujo de trabajo semanal en GSC