Por Miguel Ángel Jiménez, Head of SEO en Gecko Studio
Hay webs que llevan meses perdiendo posiciones sin que nadie haya cambiado una sola línea del contenido. El tráfico baja despacio, las páginas que antes aparecían en primera posición van cayendo a la segunda y a la tercera, y la explicación no está en los textos ni en los títulos. Está en la capa que no se ve al navegar: el código, el servidor, la configuración.
La auditoría SEO técnica es el diagnóstico de esa capa. Revisa cómo Google accede a la web, qué puede leer y qué no, a qué velocidad la procesa y si hay contradicciones en las señales que le estamos enviando. Sin ese diagnóstico previo, cualquier trabajo de contenido o de enlaces construye sobre una base que puede estar agrietada.
Este artículo recorre los bloques principales de una auditoría técnica —indexación y rastreo, Core Web Vitals, canonicals, redirecciones, errores de servidor— e incluye un bloque específico sobre WordPress, donde se concentran la mayoría de los problemas que vemos en cartera. Todo con un ejemplo real anonimizado: cifras de una auditoría de verdad, sin nombres ni dominios identificables.
Si quieres entender primero cómo encaja lo técnico dentro de una auditoría SEO completa, empieza por la guía de auditoría SEO. Si ya tienes claro el marco general y quieres profundizar en la capa técnica, estás en el sitio correcto.
Qué analiza (exactamente) una auditoría SEO técnica
La auditoría técnica no revisa el contenido de las páginas ni la estrategia de palabras clave: eso corresponde al análisis SEO on-page. Se centra en la infraestructura: todo lo que determina si Google puede encontrar las páginas, leerlas correctamente y valorarlas sin fricciones.
Los bloques que cubre son cinco para una web monoidioma estándar:
- Rastreo e indexación — ¿puede Google entrar en cada URL y decide incluirla en el índice?
- Core Web Vitals y velocidad — ¿a qué velocidad carga la página en las condiciones reales de un usuario?
- Canonicals y duplicados — ¿sabe Google cuál es la versión «original» de cada contenido?
- Redirecciones — ¿son correctas, directas y sin cadenas innecesarias?
- Errores de servidor — ¿responde el servidor sin errores ni timeouts que recorten el presupuesto de rastreo?
En webs multiidioma se añade un sexto bloque —hreflang e internacionalización—, que desarrollamos en el artículo sobre auditoría SEO internacional. Para una web monoidioma como la del caso que analizamos aquí, ese bloque no aplica y no se trata como fallo: es simplemente un módulo que no existe porque no hay versiones de idioma que coordinar.
Cada uno de estos bloques puede estar funcionando bien, mal o en un punto intermedio que no genera síntomas inmediatos pero erosiona el rendimiento. El trabajo de la auditoría es cuantificar exactamente en qué estado está cada uno y qué impacto tiene sobre el conjunto.
El caso real: una empresa de alquiler de coches con 68/100 en móvil
Para que los problemas técnicos no queden en abstracto, los ilustramos con datos reales de una auditoría de nuestra cartera. Se trata de una empresa de alquiler de coches, con web monoidioma en español. Hemos eliminado el nombre, el dominio y cualquier URL identificable. Las cifras son las del proyecto real.
El dato que más llama la atención no es ningún error puntual: es que meses antes de la auditoría, el sitio puntuaba 98-99 sobre 100 en PageSpeed Insights para móvil. En el momento del análisis había caído a 68. No hubo ningún cambio en el contenido ni en la estrategia: hubo una actualización de tema y un conjunto de plugins que, de forma silenciosa, degradaron el rendimiento técnico por completo. El scorecard técnico en el momento de la auditoría:
Equivalente en texto (los mismos datos del gráfico):
| Métrica técnica | Valor real | Umbral o referencia | Estado |
|---|---|---|---|
| CWV móvil (puntuación PageSpeed) | 68/100 | ≥90 = bueno | Falla |
| LCP móvil | 3,2 s | <2,5 s = bueno | Falla |
| CLS móvil | 0,150 | <0,1 = bueno | Falla |
| INP móvil | 280 ms | <200 ms = bueno | Falla |
| CWV escritorio (puntuación PageSpeed) | 82/100 | ≥90 = bueno | Pasa / mejorable |
| LCP escritorio | 1,8 s | <2,5 s = bueno | Pasa |
| CLS escritorio | 0,08 | <0,1 = bueno | Pasa |
| Puntuación histórica móvil (antes del cambio) | 98-99/100 | — | Referencia |
| Páginas 200 (crawl) | 907 | — | OK |
| Redirecciones 301 (correctas) | 24 | Revisar cadenas | Revisar |
| Redirecciones 302 evitables | 35 | 0 (convertir a 301) | Corregir |
| Errores 404 | 2 | 0 en URLs enlazadas | Bajo / revisar |
| Timeouts (crawl) | 4 | 0 | Bajo / vigilar |
| Rastreadas, no indexadas (GSC) | 481 de 750 | Lo mínimo posible | Crítico |
| Not found (GSC) | 63 | 0 | Revisar |
| Noindex (GSC) | 45 | Solo las intencionales | Revisar |
| Duplicate canonical (GSC) | 28 | 0 | Corregir |
| Duplicate content (GSC) | 3 | 0 | Bajo / revisar |
| Hreflang | No aplica | Web monoidioma | — |
Este es el estado de partida. A continuación explicamos qué significa cada bloque, por qué importa y qué acciones produce.
Rastreo e indexación: cuando Google rastrea pero no indexa
Antes de posicionarse, una página tiene que existir para Google. El proceso es secuencial: primero el robot de Google visita la URL (rastreo), luego decide si la incluye en su índice (indexación) y solo entonces puede aparecer en resultados de búsqueda. Un problema en cualquier punto de esa cadena corta el proceso.
En el caso analizado, Google Search Console mostraba 481 páginas en estado «rastreada, no indexada» de un total de 750 URLs rastreadas: casi dos tercios del sitio que Google visita pero no incluye en el índice. Las razones más habituales:
- Contenido de baja calidad o duplicado — páginas con poco contenido propio, variaciones de la misma URL con parámetros distintos, o páginas de filtros de búsqueda interna que generan duplicados automáticos.
- Señales contradictorias — una página no tiene la etiqueta
noindex, pero tiene un canonical que señala a otra URL diferente. Google decide no indexarla porque entiende que la «original» es la otra. - Thin content sistemático — páginas de listado o de categoría con muy pocas entradas que Google considera insuficientes para el usuario.
Separar cuál de esas razones explica el grueso de las 481 exclusiones es uno de los primeros trabajos de la auditoría. En este caso, los 28 «duplicate canonical» de GSC y las páginas generadas por la estructura de filtros y parámetros del sitio explicaban la mayoría. La solución no pasa por «forzar» la indexación, sino por eliminar las señales contradictorias y consolidar el contenido disperso.
También hay 63 not found (URLs que Google conoce pero que han desaparecido) y 45 noindex que conviene revisar: algunas son intencionales (páginas de gestión interna), otras no lo son. Los 4 timeouts del rastreo, aunque son un número bajo, merecen atención porque cada timeout es presupuesto de rastreo desperdiciado.
Core Web Vitals: la degradación silenciosa tras actualizar WordPress
Las Core Web Vitals son el conjunto de métricas de experiencia de usuario que Google usa como señal de posicionamiento. No miden «velocidad» en abstracto: miden tres cosas concretas con umbrales definidos —cuatro en la métrica de interactividad INP, que Google incorporó como señal oficial en 2024—.
El dato más revelador de este caso no es el valor actual: es la trayectoria. Meses antes de la auditoría, el sitio alcanzaba 98-99 puntos sobre 100 en móvil. No había cambiado el servidor, no había cambiado el contenido: hubo una actualización de tema y un conjunto de plugins adicionales que se instalaron en ese período. El resultado fue un desplome de 30 puntos en la puntuación móvil. Es el patrón de degradación técnica más habitual en WordPress y el que más cuesta detectar a tiempo porque ocurre de forma gradual y sin alertas.
LCP (Largest Contentful Paint) mide cuánto tarda en aparecer el elemento principal visible de la página —normalmente la imagen de cabecera o el titular más grande—. El umbral bueno es inferior a 2,5 segundos. En el caso analizado, el LCP en móvil era de 3,2 segundos, superando ese límite. El culpable habitual en sitios de alquiler de coches son las imágenes de flota: fotografías de alta resolución subidas sin optimizar que se cargan completas antes de que el navegador pueda mostrar nada relevante al usuario.
CLS (Cumulative Layout Shift) mide cuánto se desplaza el contenido de la pantalla mientras carga. Un CLS de 0,150 (umbral bueno: por debajo de 0,1) indica que hay elementos que se mueven durante la carga: habitualmente imágenes sin dimensiones definidas en el HTML, banners de promoción que aparecen tarde y empujan el texto, o widgets de comparador de precios que se renderizan después del resto de la página.
INP (Interaction to Next Paint) mide cuánto tarda la página en responder visualmente a una acción del usuario —un clic, un toque en pantalla—. Con 280 ms (umbral bueno: por debajo de 200 ms), el sitio está en zona de fallo. Esto ocurre cuando hay scripts de terceros que bloquean el hilo principal: típicamente, integraciones de seguimiento, widgets de reserva en tiempo real o scripts de comparadores que se ejecutan de forma síncrona.
La diferencia entre el rendimiento en móvil (68/100) y en escritorio (82/100, con todos los indicadores en verde) es diagnóstica en sí misma. Significa que el problema no es el servidor —si fuera lento, afectaría a ambas plataformas por igual—. La causa está en cómo se sirven los recursos al dispositivo: imágenes que no se redimensionan para móvil, scripts que bloquean el renderizado y que en escritorio pasan desapercibidos porque el hardware es más potente, y recursos de terceros que se cargan igualmente aunque no sean visibles en pantalla pequeña.
El dato que importa para el posicionamiento es este: desde 2021, Google usa los datos de campo de usuarios reales (Chrome User Experience Report) para evaluar las Core Web Vitals, no solo los datos de laboratorio de PageSpeed. Si los usuarios reales de la web en móvil experimentan un LCP de 3,2 segundos y un INP de 280 ms, eso es lo que Google está midiendo. No hay forma de maquillar esos números sin mejorar el rendimiento real.
Canonicals y «duplicate canonical»: cuando Google elige una URL diferente a la declarada
El canonical es una etiqueta HTML que le dice a Google: «de todas las versiones posibles de esta URL, esta es la que cuenta». Su función es resolver el problema de duplicados: una misma página accesible desde varias URLs (con y sin www, con y sin barra final, en HTTP y HTTPS, con parámetros de sesión o de campaña añadidos).
En el caso analizado, el rastreo detectó 3 páginas con canonical cruzado. Tras revisarlos, los tres eran técnicamente correctos: páginas que consolidan variantes con parámetros UTM de campañas de publicidad hacia la URL limpia. No son un problema.
El problema real está en GSC: 28 páginas en estado «duplicate canonical». Esto significa algo diferente a los canonicals cruzados del rastreo: aquí Google ha decidido que el canonical declarado en el código no es el canonical que va a respetar. Ha elegido una URL diferente como la «original». Las razones más frecuentes de este comportamiento:
- Señales contradictorias entre canonical y enlazado interno — la página declara un canonical hacia sí misma, pero los enlaces internos apuntan mayoritariamente a una variante con parámetros o con distinta estructura. Google sigue los enlaces internos como señal de autoridad y puede ignorar el canonical declarado.
- Contenido insuficientemente diferenciado — cuando dos URLs tienen un contenido muy similar, Google puede decidir cuál indexar independientemente de lo que diga el canonical.
- Redirects que crean confusión — una URL con canonical declarado que además redirige (o cuyo destino redirige) genera una señal ambigua que Google resuelve por su cuenta.
El dato de «28 duplicate canonical» en GSC es el síntoma más directo de que hay un problema de señales contradictorias en el sitio. No es un error de configuración técnica puntual: es una discrepancia entre lo que el sitio le dice a Google y lo que Google observa al rastrearlo. Resolverlo requiere auditar cada una de esas 28 páginas para identificar qué señal está ganando sobre el canonical declarado.
Redirecciones: por qué las 302 cuestan más de lo que parece
Una redirección bien ejecutada transfiere la autoridad de la URL antigua a la nueva. El tipo de redirección importa: una 301 es permanente y transfiere la autoridad; una 302 es temporal y, en teoría, no transfiere autoridad porque le indica a Google que la URL original volverá a ser accesible en algún momento.
En el caso analizado, el crawl encontró 35 redirecciones 302 que deberían ser 301. Esto ocurre frecuentemente en sitios donde alguien configuró redirecciones hace tiempo, las marcó como temporales por error o porque «así lo hacía el sistema», y nadie las revisó después. El impacto es doble:
- Pérdida potencial de autoridad — los enlaces externos que apuntan a URLs que redirigen mediante 302 pueden no estar transfiriendo correctamente su peso a la URL de destino.
- Señal de temporalidad en URLs definitivas — si la estructura de URLs del sitio está consolidada, no tiene sentido mantener redirecciones marcadas como temporales; Google puede decidir que la URL original «volverá» y seguir rastreando ambas.
La solución es técnicamente trivial: cambiar el código de respuesta de 302 a 301 en el servidor o en el gestor de redirecciones. El trabajo de auditoría es identificar cuáles de esas 35 URLs tienen enlaces externos o internos relevantes, para priorizar el cambio donde el impacto es mayor.
WordPress: los problemas técnicos más habituales en la plataforma más extendida
WordPress gestiona aproximadamente el 43 % de los sitios web del mundo. También concentra una alta proporción de los problemas técnicos SEO que diagnosticamos en cartera, no porque la plataforma sea deficiente, sino porque su ecosistema de plugins y su flexibilidad de configuración permiten combinaciones que individualmente funcionan y en conjunto rompen cosas. El caso del alquiler de coches —con una degradación de 98-99 a 68 puntos en móvil tras una actualización— es el patrón más representativo.
Esta sección usa conocimiento técnico verificable sobre los patrones de fallo más frecuentes en webs WordPress auditadas; no añade cifras inventadas al caso.
El cambio de tema que nadie auditó
Un cambio de tema en WordPress no es solo un cambio visual. El tema controla cómo se cargan las fuentes, los scripts y los estilos. Un tema mal codificado puede cargar decenas de archivos CSS y JavaScript adicionales, incluir fuentes de Google Fonts de forma síncrona, añadir scripts de animación o sliders que bloquean el renderizado, o generar elementos sin dimensiones definidas que disparan el CLS. En el caso analizado, la degradación de 30 puntos se produjo exactamente por este mecanismo: el nuevo tema cargaba más recursos y de forma menos eficiente que el anterior.
La buena práctica no es evitar los cambios de tema, sino medirlos antes y después. PageSpeed Insights tarda menos de un minuto en dar un número. Si el número cae, el cambio de tema tiene un coste técnico que hay que decidir si se asume o si se optimiza antes de publicar.
La casilla que nadie recuerda haber marcado
WordPress incluye en Ajustes → Lectura una opción llamada «Disuadir a los motores de búsqueda de indexar este sitio». Está pensada para webs en construcción. Si está activa en producción, el resultado es un robots.txt que bloquea todo el rastreo: Google no puede indexar nada. Es el error más silencioso que existe porque la web funciona perfectamente para los usuarios, pero en Search Console aparece sin páginas indexadas.
Ocurre con más frecuencia de la esperada tras restauraciones de backup, migraciones de staging a producción o instalaciones de plugins de mantenimiento que activan temporalmente el modo de mantenimiento y no lo desactivan correctamente. La verificación es inmediata: Ajustes → Lectura, comprobar que la casilla está desmarcada.
Páginas que WordPress genera sin que nadie las pida
Una instalación WordPress estándar genera URLs que a menudo no tienen utilidad SEO:
- Páginas de autor (
/author/nombre/) — si el sitio tiene un solo autor, estas páginas muestran exactamente el mismo contenido que la portada del blog, pero en una URL diferente. Google las interpreta como contenido duplicado. - Páginas de etiqueta (
/tag/nombre/) — si se usan etiquetas con una sola entrada, cada una genera una URL con un único artículo, lo que Google interpreta como thin content. - Páginas de resultados de búsqueda interna (
/?s=termino) — cada búsqueda que un usuario hace en el sitio genera una URL indexable con contenido variable e impredecible. - Paginación del blog (
/page/2/,/page/3/…) — las páginas de archivo paginadas con pocas entradas por página multiplican las URLs con contenido parcial.
El volumen de estas URLs puede superar al de las páginas de contenido real en sitios con muchas categorías y etiquetas. La solución estándar es usar un plugin SEO (Yoast, Rank Math) para marcar esos tipos de contenido como noindex, pero hay que hacerlo con criterio: no todo lo que WordPress genera debe bloquearse automáticamente. En un sitio de alquiler de coches, por ejemplo, las páginas de categorías de vehículos o de destinos pueden tener valor SEO real si tienen contenido editorial suficiente.
Sitemaps duplicados y metadatos contradictorios
Un problema frecuente en instalaciones con múltiples plugins activos: dos o más plugins generan sitemaps XML independientes. La caché XML de un plugin de rendimiento puede estar sirviendo un sitemap desactualizado mientras el plugin SEO genera uno al día. Si hay discrepancias entre ellos (URLs que aparecen en uno pero no en el otro, fechas de última modificación distintas), Google puede no saber cuál es el sitemap canónico.
La misma lógica aplica a los metadatos: si el tema activo genera sus propias etiquetas og:title y og:description además del plugin SEO, el resultado son metadatos duplicados o contradictorios en el <head> de cada página. Los buscadores suelen ignorar las repeticiones y quedarse con la primera instancia, que puede no ser la que hemos configurado en el plugin SEO.
Imágenes sin optimizar: el culpable directo del LCP alto
WordPress no optimiza las imágenes al subirlas. Una fotografía de un coche subida directamente desde cámara puede pesar 6-10 MB y tener dimensiones de 5.000 × 3.000 píxeles. En móvil, esa imagen se muestra en una columna de 400 píxeles de ancho, pero el navegador la descarga completa antes de redimensionarla. El resultado directo es un LCP alto y una puntuación de PageSpeed baja en móvil, exactamente como en el caso analizado.
Las tres correcciones básicas que resuelven la mayoría de los casos:
- Compresión y redimensionado automático al subir (plugins como ShortPixel, Imagify o Smush).
- Formato WebP o AVIF en lugar de JPEG o PNG, que a igual calidad visual pesan entre un 25 y un 50 % menos.
- Atributo
loading="lazy"en imágenes fuera del área visible inicial, para que no bloqueen la carga del contenido principal.
La imagen del hero o de cabecera —la que aparece inmediatamente visible sin scroll— debe tratarse de forma diferente: no debe tener lazy load, sino preload explícito con la etiqueta <link rel="preload"> en el <head>. Es uno de los cambios con mayor impacto directo sobre el LCP.
Actualizaciones que introducen regresiones técnicas
Cada actualización de WordPress, de un tema o de un plugin puede introducir cambios que afecten al SEO sin que haya ningún aviso: un plugin de seguridad actualizado puede añadir reglas al robots.txt, un tema actualizado puede incluir scripts adicionales que aumentan el tiempo de bloqueo del renderizado, un cambio en WooCommerce puede alterar la estructura de URLs de fichas de producto y generar 404 en las antiguas. El caso del alquiler de coches es la demostración exacta de este patrón.
La buena práctica no es dejar de actualizar —las actualizaciones son necesarias por seguridad—, sino establecer un protocolo de verificación después de cada una: revisión rápida de PageSpeed, comprobación del robots.txt, y una pasada por Search Console para detectar nuevos errores de cobertura antes de que se acumulen.
Cómo priorizar los hallazgos técnicos
Una auditoría técnica puede generar decenas de problemas detectados. No todos tienen el mismo impacto y no todos requieren el mismo esfuerzo de corrección. La forma de priorizar que usamos en Gecko Studio combina dos criterios: impacto sobre el rastreo y la indexación (lo que bloquea a Google directamente va primero) y volumen de páginas afectadas (un error que afecta a 481 URLs tiene más urgencia que uno que afecta a 2).
Aplicado al caso analizado, la secuencia de acción sería:
| Prioridad | Problema | Impacto |
|---|---|---|
| 1 — Crítica | 481 rastreadas, no indexadas (de 750) | Casi dos tercios del sitio fuera del índice; diagnóstico compuesto que requiere desgranar causas (duplicate canonical, thin content, señales contradictorias) |
| 2 — Crítica | Core Web Vitals móvil (68/100, 3 señales en fallo) | Señal de posicionamiento negativa directa; el dato histórico 98→68 prueba que la causa es identificable y reversible |
| 3 — Alta | 28 duplicate canonical (GSC) | Google está ignorando los canonicals declarados en esas páginas; hasta resolverlo, las señales de autoridad no se consolidan correctamente |
| 4 — Alta | 35 redirecciones 302 evitables | Posible pérdida de autoridad en URLs con enlaces entrantes; corrección técnicamente sencilla |
| 5 — Media | 63 not found (GSC) | URLs que Google conoce pero que devuelven error; revisar cuáles tienen enlaces y redirigirlas |
| 6 — Media | 45 noindex (GSC) | Verificar que todas son intencionales; cualquier noindex accidental suprime páginas que deberían estar en el índice |
| 7 — Baja | 4 timeouts (crawl) y 2 errores 404 | Volumen bajo; vigilar para que no crezcan |
El criterio que más confunde en la práctica es el de las 481 «rastreadas, no indexadas». Mucha gente quiere atacarlo directamente, como si fuera un número que se puede reducir de golpe. En realidad es un síntoma que tiene varias causas, y cuando se resuelven los problemas de duplicate canonical, thin content y señales contradictorias, el número baja de forma natural. Atacarlo sin resolver las causas raíz no funciona.
De la auditoría técnica al plan de acción en auditoría SEO técnica
Una auditoría técnica bien ejecutada no termina en un informe de hallazgos: termina en un plan de acción ordenado por impacto con responsable asignado para cada tarea. La diferencia entre una auditoría que mueve el posicionamiento y una que acaba en un cajón es exactamente esa: la traducción de los datos técnicos en acciones concretas con criterio de priorización.
El bloque técnico es el cimiento de cualquier estrategia SEO. Sin él en orden, el trabajo de contenido rinde por debajo de su potencial y el trabajo de enlazado externo no se distribuye correctamente por el sitio. Por eso en nuestra metodología siempre resolvemos primero la capa técnica antes de pasar al análisis on-page o a la construcción de autoridad.
Si quieres ver cómo encaja este bloque dentro de una auditoría SEO completa, la guía de auditoría SEO cubre todas las capas en secuencia. Si prefieres que revisemos la capa técnica de tu web directamente, en Gecko Studio realizamos auditorías SEO técnicas y completas con informe detallado, scorecard de métricas reales y plan de acción priorizado.
Preguntas frecuentes sobre auditoría SEO técnica
¿Qué es una auditoría SEO técnica y qué analiza exactamente?
Una auditoría SEO técnica es el diagnóstico sistemático de todos los factores que afectan a cómo Google accede, rastrea, indexa y procesa una web. Analiza el estado del rastreo e indexación (qué páginas puede leer Google y cuáles no), las Core Web Vitals y velocidad de carga, la configuración de canonicals y duplicados, las redirecciones y los errores de servidor. En webs monoidioma no incluye hreflang porque no hay versiones de idioma que coordinar; ese módulo aplica cuando la web tiene contenido en más de un idioma, como se explica en el artículo sobre auditoría SEO internacional.
¿Cada cuánto hay que hacer una auditoría SEO técnica?
Como mínimo una vez al año, y siempre después de cambios significativos: migración de dominio o plataforma, rediseño web, actualizaciones masivas de plugins o cambios en la estructura de URLs. Los Core Web Vitals, en particular, deben monitorizarse de forma continua porque una sola actualización de tema o de plugin puede degradarlos —el caso del sitio de alquiler de coches, con una caída de 30 puntos en móvil tras una actualización, es el ejemplo exacto—. En webs de alta actividad es recomendable una revisión técnica trimestral.
¿Puede una web tener errores técnicos graves y seguir teniendo tráfico?
Sí, y es la situación más peligrosa. Los errores técnicos rara vez cortan el tráfico de golpe: lo erosionan de forma gradual, posición a posición, durante meses. Una web puede funcionar perfectamente para los usuarios mientras Google va excluyendo páginas del índice porque no puede rastrearlas correctamente o porque las Core Web Vitals están en zona de fallo. Cuando el problema se detecta, el daño ya está hecho y la recuperación lleva tiempo. La auditoría técnica preventiva existe precisamente para detectar esa degradación antes de que sea visible en las métricas de negocio.
¿Qué es el presupuesto de rastreo y por qué afecta al SEO técnico?
El presupuesto de rastreo es el límite de URLs que Googlebot visita en un sitio durante un periodo de tiempo. No es fijo: depende de la autoridad del dominio, del tamaño del sitio y de la velocidad de respuesta del servidor. Si hay muchas páginas con errores (timeouts, 404) o con contenido irrelevante (thin content, duplicados sin consolidar), Google gasta ese presupuesto en URLs que no aportan valor y puede no llegar a rastrear las páginas importantes. En el caso analizado, los 4 timeouts del crawl son un número bajo, pero las 481 «rastreadas, no indexadas» apuntan a que una parte significativa del presupuesto se gasta en páginas que Google visita pero descarta.
¿Qué problemas técnicos SEO son más frecuentes en WordPress?
Los más habituales que diagnosticamos son: la casilla de «disuadir indexación» activada en Ajustes → Lectura (bloquea todo el rastreo), cambios de tema que introducen regresiones en Core Web Vitals, imágenes sin optimizar que disparan el LCP en móvil, páginas de autor y etiqueta indexables con contenido duplicado o thin content, sitemaps XML generados por dos plugins distintos con contenido contradictorio, y conflictos entre plugins de caché y plugins SEO que sirven metadatos desactualizados. La mayoría tienen solución conocida con configuración adecuada del plugin SEO y un protocolo de verificación tras actualizaciones.
¿Qué diferencia hay entre una auditoría SEO técnica y una auditoría SEO completa?
La auditoría técnica cubre exclusivamente la capa de infraestructura: cómo Google accede y procesa la web. Una auditoría SEO completa incluye además el análisis on-page (títulos, metas, estructura de contenido), el análisis de palabras clave e intención de búsqueda, el perfil de enlaces externos y el análisis de competidores. La capa técnica es el primer bloque que se revisa en cualquier auditoría porque condiciona el rendimiento del resto: si hay problemas de rastreo, de velocidad o de canonicals sin resolver, el trabajo en las capas superiores rinde por debajo de su potencial.