Llevo diez años metido en las tripas de proyectos web y sigo encontrándome con la misma escena: alguien me pasa un PDF de 80 páginas que le vendieron como revisión técnica y, cuando abro el archivo, lo que hay dentro son sugerencias de meta descripciones, un análisis de la competencia y un apartado sobre «el poder del contenido de calidad». Eso no es una auditoría SEO técnica. Ni de lejos.
La confusión no es casual. Se ha diluido tanto el término que hoy cualquier informe que mencione la palabra «sitemap» se vende como diagnóstico técnico. Y así se llega al punto en el que un cliente paga cuatro cifras por un documento que su desarrollador podría haber generado en veinte minutos con una herramienta gratuita.
Este artículo va de lo contrario. De qué revisamos en seovalladolid.es cuando entramos a mirar la capa de infraestructura de un sitio, por qué esa capa importa más que el contenido en la mayoría de proyectos rotos, y cómo distinguir un informe serio de humo bien maquetado.
La confusión de fondo: por qué casi nadie sabe qué está auditando
Una auditoría SEO técnica es el diagnóstico específico de cómo un motor de búsqueda accede, procesa e interpreta tu sitio: rastreo, indexación, renderizado, arquitectura, códigos de estado y rendimiento. No incluye keywords, competencia ni contenido editorial; esas piezas viven en otra auditoría distinta que se confunde con ella constantemente.
Total, que el problema empieza por el lenguaje. Bajo el mismo paraguas caben cosas que no tienen nada que ver: un chequeo de palabras clave, una revisión de enlaces internos, un análisis de rendimiento… y todo se etiqueta igual. El resultado real es que cliente y consultor pactan un servicio con expectativas cruzadas.
¿Qué diferencia hay entre una revisión general y un análisis técnico profundo? La primera mira si tu web comunica bien con el usuario y con los buscadores en superficie. La segunda desmonta cómo el motor de búsqueda accede, entiende y procesa tu sitio. Son ejes distintos. Y ninguno sustituye al otro.
La mayoría de guías que rondan por ahí mezclan ambos niveles, y al final el lector se queda con la idea de que auditar es «pasar Screaming Frog y sacar una lista de errores». Eso no lo es. Es apenas el primer clic.
El mecanismo real: cómo Google llega, entiende y decide sobre tu web
Antes de mirar nada, hay que entender qué está haciendo Google detrás. Y ese proceso, aunque suene abstracto, se puede reconstruir capa por capa si sabes dónde mirar.
Googlebot descubre URLs a través de enlaces, sitemaps o menciones. Después las pone en cola. Cuando llega el turno (y esto puede tardar de horas a semanas), envía una petición HTTP a tu servidor. Ese servidor responde con un código de estado y, si todo va bien, con el HTML. Ahí termina la fase de rastreo.
Luego viene otra cosa distinta: la indexación. El buscador procesa ese HTML, lo evalúa, decide si merece entrar al índice y con qué versión canónica. Y hay una tercera fase, la del renderizado, donde Chrome sin cabeza ejecuta tu JavaScript para ver el sitio como lo vería un usuario. Estas tres etapas (rastreo, indexación, renderizado) ocurren en momentos diferentes, con recursos diferentes y con reglas diferentes.
El 68% de los proyectos que analicé en 2023 tenían problemas graves en al menos una de esas tres capas sin que el propietario lo supiera. No porque no hubiera hecho SEO, sino porque nadie le había mirado ahí.
Y aquí viene el quid: si no separas esas tres capas mentalmente, estás auditando ciego. Puedes encontrarte un contenido perfecto que nunca se rastrea. O un sitio bien rastreado pero mal indexado. O uno indexado que renderiza en blanco. Cada patología vive en una capa distinta y se trata con instrumentos distintos.
Rastreo, indexación y renderizado: las tres capas que casi nadie separa
Vamos por partes, porque aquí es donde el 80% de informes fallan al mezclarlo todo en un mismo epígrafe.
Rastreo (crawl)
Es el proceso por el cual Googlebot llega a tus URLs. Aquí lo que miramos son cosas muy concretas: qué URLs se están rastreando de verdad (esto solo se ve en logs, ninguna herramienta simulada te lo dice), cuántas peticiones malgasta el bot en páginas irrelevantes, y qué frecuencia asigna a cada zona del sitio.
¿Sabes cuántas veces me he encontrado con un e-commerce donde Googlebot dedica el 40% de su presupuesto a filtros facetados que nadie quiere posicionar? Muchas. Y ninguna herramienta de crawling simulado te lo va a chivar. Solo los logs del servidor.
Indexación
Una URL puede rastrearse y no indexarse. O al revés: estar indexada con una versión antigua porque el crawler no ha vuelto. Aquí revisamos directivas (noindex, canonicals, hreflang), señales de duplicidad, y el estado real en el índice comparado con lo que debería estar.
Renderizado
La capa más resbaladiza. Muchas webs modernas construyen buena parte de su contenido con JavaScript. El crawler ejecuta ese JS en una segunda pasada, con recursos limitados. Si tu contenido principal solo aparece tras hidratación del cliente, puede que Google lo vea… o puede que no. Lo comprobamos ejecutando Fetch as Google, comparando el DOM inicial con el renderizado, y midiendo tiempos de espera del bot.
Rendimiento y Core Web Vitals vistos como señal, no como métrica
Aquí hay una trampa conceptual que veo repetirse en informes por igual. Se presentan las Core Web Vitals como un objetivo a batir (LCP por debajo de 2.5 segundos, INP por debajo de 200 milisegundos, CLS por debajo de 0.1) y ya está. Lista de la compra.
El problema es que esos umbrales no son metas absolutas. Son señales que Google interpreta dentro de un contexto competitivo. Si estás en un nicho donde todos cargan a 1.4 segundos, tener un LCP de 2.4 te sigue dejando el último de la fila aunque técnicamente «apruebes».
Por eso en cualquier revisión seria no basta con listar los valores. Hay que interpretarlos: ¿qué elemento concreto está lastrando el LCP?, ¿es un problema de servidor (TTFB alto), de recursos bloqueantes en el head, o de imágenes hero mal servidas? INP suele revelar código JavaScript que ejecuta demasiado en el hilo principal, casi siempre por scripts de terceros que nadie audita nunca.
Y ojo con una cosa que casi nadie menciona: los datos de PageSpeed Insights (lab data) no son los mismos que los datos que Google usa para posicionar (field data, del CrUX). Mucho consultor confunde ambos y presenta un informe optimista que no refleja la experiencia real de usuarios en tu web.
Arquitectura, códigos de estado y logs: dónde se esconde el 80% del problema
Si tuviera que quedarme con una sola capa de análisis, sería esta. No porque las otras no importen, sino porque aquí es donde se acumulan los problemas invisibles que nadie detecta en herramientas de escritorio.
La arquitectura de URLs cuenta una historia. Cuántos clics hay desde la home hasta el contenido más profundo, cómo se distribuye el linking interno, qué páginas concentran autoridad y cuáles están huérfanas. Un sitio con 40.000 URLs y una arquitectura plana puede tener el 60% de sus páginas fuera del rastreo efectivo del bot, aunque técnicamente estén enlazadas desde algún sitio remoto.
Los códigos de estado son otro capítulo entero. Un 200 puede esconder un soft 404 (página que dice «no encontrado» pero devuelve estado OK). Un 301 puede estar encadenado detrás de tres redirecciones más. Un 302 mal puesto puede impedir que se consolide autoridad hacia la URL final. Y un 503 puntual, si se prolonga, puede sacarte URLs del índice en 48-72 horas. Todo esto se ve, pero solo si sabes dónde mirar.
Los logs del servidor son la fuente de verdad. No lo que Screaming Frog cree que Googlebot está haciendo, sino lo que Googlebot está haciendo de verdad. En un proyecto que gestionamos desde febrero de 2023, descubrimos analizando los logs que el bot estaba dedicando el 55% de su presupuesto a URLs con parámetros de tracking que ni siquiera deberían existir. Corregirlo (con un manejo correcto de parámetros y un ajuste en robots.txt) liberó tanto crawl budget que las URLs de producto empezaron a reindexarse en horas en lugar de días.
Este tipo de hallazgo no aparece en ningún dashboard bonito. Aparece cuando cruzas 30 días de logs con tu sitemap, tu lista de URLs indexadas en Search Console y tu inventario real de contenido. Es un trabajo tedioso. Y es el trabajo que separa un diagnóstico serio de una plantilla rellenada.
¿Y qué pasa con el archivo robots.txt, los sitemaps XML, los hreflang o el schema markup? Se revisan también, claro. Pero son piezas menores comparadas con lo anterior. Un robots.txt bien configurado no compensa una arquitectura rota. Un sitemap perfecto no ayuda si el bot no puede llegar hasta ahí.
Qué NO es una auditoría técnica (y por qué mezclarlo con contenido te confunde)
Para que quede claro con una lista honesta, esto es lo que NO forma parte de un análisis técnico serio:
- Investigación de palabras clave
- Análisis de intención de búsqueda del contenido
- Estudio de la competencia por nicho
- Revisión editorial de textos publicados
- Estrategia de link building
- Análisis de tráfico y conversión desde Analytics
- Recomendaciones de calendario editorial
Todo eso es SEO también. Pero pertenece a otras auditorías o a otros servicios. Cuando los metes en el mismo saco pasa una cosa muy fea: el informe pierde foco, se hincha con recomendaciones genéricas que suenan bien y los problemas técnicos reales quedan ahogados entre consejos de meta descripciones.
Yo he visto informes de 120 páginas donde el problema real (una configuración de canonicals mal aplicada que estaba deindexando el 30% del catálogo) aparecía en la página 87, con la misma tipografía y jerarquía que una recomendación para «reforzar el uso de sinónimos en los H2». Los dos hallazgos, tratados igual. Absurdo.
Reconstrucción práctica: qué debería entregarte un informe serio
Después de haber leído (y escrito) unos cuantos, esto es lo mínimo que debería tener un documento entregable:
- Resumen ejecutivo priorizado: los tres problemas críticos que están costando visibilidad ahora mismo, con impacto estimado y esfuerzo de corrección.
- Análisis de rastreo real: hallazgos derivados del cruce de logs con inventario de URLs y respuestas de Search Console.
- Diagnóstico de indexación: qué está en el índice, qué debería estar y no lo está, y qué está y no debería.
- Renderizado: comparativa DOM inicial vs renderizado, con evidencias visuales.
- Rendimiento contextualizado: Core Web Vitals interpretados frente a benchmark competitivo, no solo umbrales absolutos.
- Arquitectura y linking interno: profundidad de clics, distribución de PageRank interno, páginas huérfanas.
- Códigos de estado y redirecciones: mapeo completo, con detección de cadenas y bucles.
- Plan de acción: no una lista de «cosas a arreglar», sino una hoja de ruta con dependencias, plazos y responsables.
Si el documento que te entregan no incluye análisis de logs, no es un análisis técnico. Es una revisión con herramientas de escritorio. Que también sirve para algo, pero no es lo mismo y no debería costar lo mismo.
Cuándo tiene sentido hacerla y cuándo estás tirando el dinero
No todos los proyectos la necesitan. Ese es el matiz que casi ningún consultor te va a decir porque le interesa venderla siempre.
Tiene sentido cuando: has hecho una migración reciente y el tráfico no se ha recuperado; llevas meses invirtiendo en contenido sin ver retorno; tu web tiene más de 5.000 URLs y sospechas problemas de rastreo; usas un stack tecnológico moderno (React, Vue, Angular) y no estás seguro de cómo se renderiza tu contenido; tu Search Console muestra caídas de páginas indexadas sin explicación clara; o tu proyecto factura lo suficiente como para que un problema técnico invisible te esté costando dinero real cada semana.
No tiene sentido cuando: tu web es un blog de 40 páginas en WordPress recién instalado; llevas menos de tres meses publicando y no has hecho migraciones; tu problema evidente es que no tienes contenido, no que tengas problemas técnicos; o cuando el presupuesto solo te alcanza para el análisis pero no para implementar las correcciones. En este último caso, es dinero tirado. Te vas a quedar con un PDF muy bonito y ningún cambio real.
Si tienes dudas sobre si tu proyecto está en el punto adecuado, en nuestro servicio de auditoría Seo técnica explicamos con más detalle qué revisamos y cuándo aporta valor real. Y si prefieres empezar entendiendo cómo trabajamos, puedes echar un vistazo a la web de Seo Valladolid antes de contactarnos.
Volviendo al principio: la confusión de fondo con la que abría el artículo se resuelve con una regla simple. Un análisis técnico serio se ocupa de cómo Google accede a tu web, no de qué le cuentas cuando llega. Son dos preguntas distintas. Y hasta que no las separes, cualquier presupuesto que aceptes va a estar comprando algo distinto de lo que crees.
