Una auditoría SEO técnica no empieza con una herramienta abierta ni con un PDF de 80 páginas que nadie lee. Empieza con una pregunta incómoda: ¿qué está impidiendo que Google rastree, renderice e indexe correctamente tu web corporativa? Si no puedes responderla con datos, lo que tienes es una lista de tareas, no una auditoría.
Este artículo describe la secuencia exacta de configuración que aplico en proyectos B2B con cientos o miles de URLs, ordenada por dependencias: cada paso produce el dato que alimenta el siguiente. Si te saltas el orden, acabarás recopilando métricas que no puedes interpretar.
Paso 0: define el alcance antes de tocar una herramienta
En una empresa con varias líneas de negocio, el error más caro es auditar «todo el dominio». Antes de configurar nada, delimita:
- Subdominios incluidos: blog, tienda, área de cliente, help center. Decide si el área privada entra (normalmente no, pero conviene documentarlo).
- Idiomas y versiones regionales: si tienes /es/, /mx/ y /ar/, cada una necesita revisión de hreflang propia.
- Stakeholders: quien aprueba los cambios de plantilla suele estar en IT, no en marketing. Identifícalo en esta fase o el resto del proceso se bloquea.
Un caso real: una empresa de servicios industriales con 4 idiomas descubrió en la fase de alcance que su help center vivía en un subdominio con CMS distinto y sin acceso a logs. Eso cambió por completo la metodología del resto de la auditoría: sin logs, el análisis de rastreo tuvo que basarse en muestras de Search Console y en crawls con user-agent de Googlebot.
Paso 1: configura el acceso a los datos de origen
Sin esta base, cualquier auditoría es especulativa. Necesitas, como mínimo:
Search Console
Verifica propiedad por prefijo de URL siempre que puedas (permite segmentar por subdirectorio) y mantén la propiedad de dominio como respaldo. Comprueba que el usuario que usarás tiene permiso completo, no restringido: el permiso restringido oculta datos de rendimiento y de índice que necesitarás después.
Analítica
Si usas GA4, asegúrate de que el flujo de datos web lleva activo al menos 90 días. Con menos histórico, cualquier comparación de tráfico orgánico antes/después de un cambio técnico es ruido. Configura un segmento de tráfico orgánico que excluya dominios de referencia internos y parámetros de campaña que ensucian la atribución.
Logs del servidor
Pide acceso a los archivos de acceso (Apache o Nginx) con un mínimo de 30 días. Según la documentación oficial de Google sobre rastreo, el análisis de logs es la única fuente que muestra con certeza qué URLs visita Googlebot realmente, frente a las que tú crees que visita.
Acceso al CMS y al repositorio
Necesitarás poder leer las plantillas de cabecera, las reglas de redirección y el archivo robots.txt. Si no tienes acceso al repositorio, pide al equipo técnico que exporte la configuración de .htaccess o del middleware de redirecciones.
Paso 2: prepara el crawler con precisión
La configuración del crawler determina la calidad de todos los hallazgos posteriores. Ajustes que marcan la diferencia:
- User-agent: usa el de Googlebot para simular el rastreo móvil (Googlebot Smartphone). Muchas diferencias de contenido solo aparecen con ese agente.
- Renderizado JavaScript: actívalo solo si tu web lo necesita. En webs con mucho contenido dinámico, el renderizado dispara el tiempo de crawl y puede agotar los créditos de la herramienta. En un proyecto con 12.000 URLs, activar el renderizado completo obligó a dividir el crawl en segmentos por sección.
- Límite de velocidad: no superes 2-3 peticiones por segundo en producción sin avisar a IT. Un crawl agresivo puede activar el WAF y falsear los resultados con errores 403.
- Autenticación: si hay contenido tras login relevante para SEO (por ejemplo, fichas de producto con precios ocultos), configura cookies o cabeceras de autenticación.
Guarda la configuración del crawl. La necesitarás idéntica para comparar resultados tras los cambios.
Paso 3: valida la salud del rastreo con robots.txt y sitemaps
Antes de revisar nada más, confirma que Google puede llegar a tus URLs:
- Revisa robots.txt línea a línea. Busca bloqueos de recursos CSS/JS (rompen el renderizado) y de parámetros que sí generan contenido único.
- Comprueba que el sitemap XML solo contiene URLs canónicas, con estado 200 y no bloqueadas. Un sitemap con redirecciones o 404 es una señal de descuido que Google ignora progresivamente.
- Verifica en Search Console → Sitemaps que el archivo se procesa sin errores y que las URLs descubiertas coinciden con las que esperas.
- Usa la herramienta de inspección de URLs para las 10 páginas más importantes por negocio y confirma «La URL está en Google» y que la versión rastreada es la canónica.
Limitación honesta: si tu web tiene más de 50.000 URLs, la inspección manual no escala. En ese caso, prioriza la inspección por plantilla (una URL representativa por tipo) y complementa con el informe de «Páginas» de Search Console.
Paso 4: mapea códigos de estado y redirecciones
Exporta del crawl todas las URLs con estado distinto de 200 y clasifícalas:
- 301/302: verifica que las cadenas de redirección no superen un salto e identifica bucles. Un patrón habitual en empresas tras migraciones: /producto → /producto/ → /es/producto/ → 404. Cada salto pierde señal y añade latencia.
- 404/410: cruza la lista con Search Console para detectar URLs que aún reciben enlaces externos. Esas son las que necesitan redirección o recuperación, no las que simplemente existen.
- 5xx: si aparecen en el crawl, para. Un servidor inestable invalida cualquier otro análisis.
Documenta cada redirección con su origen, destino y motivo. Ese registro es lo que permitirá a IT ejecutar los cambios sin interpretaciones.
Paso 5: resuelve canónicas y duplicidades
Configura la revisión en tres capas:
- Canónicas declaradas: compara la etiqueta rel=canonical con la URL final tras redirecciones. Una canónica que apunta a una URL redirigida es un error frecuente en CMS con plugins de SEO mal configurados.
- Parámetros: identifica los que generan duplicados (ordenación, filtros, paginación) y decide entre canónica, noindex o bloqueo. Ojo: bloquear en robots.txt una URL con canónica impide que Google lea esa canónica.
- Variantes de URL: mayúsculas, barra final, http/https, www/no-www. Fuerza una sola versión con redirecciones a nivel de servidor, no desde el CMS.
Esto no funciona igual en todos los casos: en ecommerce con filtros facetados, la canónica por sí sola no resuelve el problema si los filtros reciben enlaces internos. Ahí necesitas además control de enlazado interno y, a veces, renderizado condicional de los enlaces de filtro.
Paso 6: audita el renderizado y el JavaScript
Compara el HTML inicial con el DOM renderizado en las plantillas clave. Busca:
- Contenido principal que solo aparece tras ejecutar JavaScript (riesgo alto si no hay renderizado del lado del servidor).
- Enlaces internos generados por JS que el crawler no descubre sin renderizado.
- Metadatos (title, canonical, hreflang) inyectados por JS y que podrían no reflejarse en el HTML servido.
Según la documentación oficial sobre renderizado, Google puede ejecutar JavaScript, pero con presupuesto de rastreo limitado y sin garantía de que todos los scripts se ejecuten. La conclusión práctica: si un enlace o un canonical solo existe tras JS, trátalo como no fiable.
Paso 7: mide Core Web Vitals con datos de campo
No te quedes con Lighthouse. Configura la revisión con datos reales:
- Exporta el informe de Core Web Vitals de Search Console por tipo de dispositivo y agrupación de URL.
- Identifica qué plantillas suspenden LCP, INP o CLS, no qué páginas sueltas.
- Prioriza por impacto: una plantilla de ficha de producto con miles de URLs y LCP deficiente pesa más que la home.
Matiz importante: los datos de campo tienen latencia (28 días en el informe de Search Console). Si acabas de optimizar imágenes, no esperes ver el cambio en la misma semana. Y si tu tráfico es bajo, puede que no haya suficientes muestras para evaluar una plantilla concreta; en ese caso, combina laboratorio y campo, y dilo en el informe.
Paso 8: consolida el informe y prioriza por dependencias
El entregable no es una lista de errores. Es una secuencia de ejecución con dependencias:
- Bloqueantes: 5xx, robots.txt que bloquea recursos, redirecciones rotas. Sin esto, el resto no importa.
- Estructurales: canónicas, duplicidades, arquitectura de enlaces internos.
- Rendimiento: Core Web Vitals por plantilla.
- Mejoras: datos estructurados, hreflang, optimización de imágenes.
Cada tarea debe indicar la URL o plantilla afectada, el equipo responsable y cómo se verificará el cambio (por ejemplo, «recrawl de las 200 URLs de la plantilla X y comparación de códigos de estado»).
Errores de configuración que veo repetirse
- Auditar con el user-agent de escritorio en webs donde el móvil sirve contenido distinto. Los hallazgos no coinciden con lo que Google indexa.
- Confiar en la cobertura de Search Console sin cruzar con logs. Hay URLs rastreadas que nunca aparecen en los informes y otras que aparecen como «excluidas» sin motivo aparente.
- Cambiar robots.txt y canónicas a la vez. Si algo empeora, no sabrás qué lo causó. Un cambio por iteración, con fecha registrada.
- Ignorar el área de cliente en el robots.txt y descubrir meses después que Googlebot consume presupuesto de rastreo en URLs de sesión.
Qué no cubre esta metodología
Una auditoría técnica no arregla un problema de intención de búsqueda ni de calidad de contenido. Si tu web rastrea e indexa correctamente pero las páginas no responden a lo que el usuario busca, los datos técnicos estarán limpios y el tráfico seguirá plano. Tampoco sustituye una revisión de enlaces tóxicos ni de autoridad de dominio: son disciplinas distintas que se complementan, no se solapan.
Y una advertencia final: ninguna auditoría garantiza mejoras de posicionamiento. Lo que garantiza es que eliminas obstáculos medibles. El resto depende de factores que no controlas desde el servidor.
Perfiles verificables: Sitio web
Publicado el 25 de October de 2026. Última revisión: 25 de October de 2026.