Auditoría SEO técnica: las correcciones que afectan antes al posicionamiento

Un dueño de negocio ejecuta una herramienta de auditoría SEO técnica en su propio sitio.

El informe devuelve cuarenta problemas marcados. JavaScript que bloquea el renderizado. Una etiqueta hreflang que falta. Varias imágenes sin texto alternativo. Unos cuantos errores 404.

En el informe no aparece cuáles de estos problemas le están costando posiciones de verdad y cuáles son solo ruido que genera una herramienta para parecer exhaustiva.

Así que el informe se hojea, se guarda en favoritos y, en su mayoría, se ignora, porque no hay un punto obvio por donde empezar.

Una auditoría seo técnica no necesita cubrir cuarenta cosas para ser útil. Necesita cubrir cuatro: si Google puede rastrear tus páginas, qué tan rápido cargan, cómo se ven en un teléfono y si tus datos estructurados son válidos. Aquí tienes cómo recorrer estas cuatro áreas en el orden que realmente afecta al posicionamiento, en lugar de revisar de arriba abajo una lista larga.

Qué revisa realmente una auditoría SEO técnica

Una auditoría técnica de SEO revisa la infraestructura de un sitio web, no lo que se escribe en él. Se pregunta si una página puede alcanzarse, leerse y mostrarse con rapidez, en cualquier dispositivo, en lugar de si el contenido de esa página es bueno.

Esa diferencia importa, porque una página técnicamente perfecta con contenido superficial y genérico tampoco posicionará bien, y una página muy bien escrita que Google no puede rastrear no posicionará en absoluto. Los dos tipos de auditoría resuelven problemas distintos.

Las cuatro áreas que cubre este artículo

La mayoría de lo que aparece en un informe de auditoría técnica cae en una de cuatro categorías: rastreabilidad, velocidad del sitio, renderizado en móvil y datos estructurados. La propia documentación de Search Essentials de Google plantea el requisito básico de forma sencilla: una página necesita ser técnicamente accesible y renderizable antes de que se evalúe cualquier otra cosa sobre ella.

Este artículo recorre esas cuatro áreas en el orden que suele importar más, empezando por si Google puede llegar realmente a tus páginas, ya que nada más en una auditoría técnica tiene sentido hasta que eso esté resuelto.

Cómo se diferencia una auditoría técnica de una auditoría de contenido

Una auditoría de contenido pregunta si una página responde una pregunta real con suficiente detalle, si está actualizada y si es la página adecuada para posicionar en una búsqueda concreta. Una auditoría técnica no pregunta nada de eso. Pregunta si la página carga, si está bloqueada y si un teléfono puede mostrarla correctamente.

Ambas auditorías importan, y un sitio normalmente necesita las dos en algún momento. Este artículo se centra en el lado técnico a propósito, porque es la parte que la mayoría de los dueños de pequeños negocios omiten por completo o intentan arreglar de golpe a partir de una lista de problemas confusa.

Diagrama que muestra las cuatro áreas de la auditoría técnica en orden de prioridad: rastreabilidad, velocidad del sitio, renderizado en móvil y datos estructurados.

Errores de rastreo: qué impide que Google lea tus páginas

Antes de que importe la velocidad de una página o su diseño en móvil, Google tiene que poder encontrarla, solicitarla y añadirla a su índice. Un error de rastreo rompe esa cadena, y ningún otro punto de la lista de una auditoría técnica compensa ese fallo.

Cómo leer el informe de indexación de páginas en Search Console

El informe de indexación de páginas de Search Console es la forma más directa de ver cómo Google está tratando realmente tus páginas, en lugar de adivinarlo desde fuera. Agrupa tus URL por estado: indexadas, o no indexadas junto con un motivo específico.

Motivos como Bloqueada por robots.txt, Error del servidor (5xx), Error de redirección y Soft 404 apuntan cada uno a una causa diferente, y cada uno necesita una solución algo distinta. Revisar este informe una vez al mes lleva unos minutos y detecta problemas mucho antes de que se traduzcan en una caída de tráfico.

Errores de rastreo comunes y sus causas

Una página bloqueada suele deberse a una línea en robots.txt pensada para otra sección del sitio que, por accidente, abarcó más de lo previsto. Un error del servidor suele significar que la página devolvió una respuesta de nivel 500 cuando Google intentó cargarla, a menudo por un problema de alojamiento o de un plugin, y no por algo relacionado con el contenido de la página.

Un error de redirección significa que Google siguió una redirección que llevó a un lugar inesperado, a menudo un bucle o un callejón sin salida. Un soft 404 es una página que devuelve un estado 200 normal pero tiene tan poco contenido que Google la trata como prácticamente vacía. Vale la pena revisarla, porque a veces indica una página que realmente necesita más texto.

Por qué una página importante bloqueada supera a cualquier otra corrección de esta lista

Un sitio puede tener una velocidad excelente, un diseño móvil impecable y datos estructurados válidos en cada página, y nada de eso importa si la página de servicio principal está bloqueada por accidente en robots.txt. Una página bloqueada no se está valorando mal. Ni siquiera se está valorando.

Por eso los errores de rastreo siempre van primero en una auditoría técnica, por delante de cualquier cosa relacionada con la velocidad o el renderizado. Nuestra guía sobre cómo lograr que Google indexe tu sitio web explica esta comprobación con más detalle, incluido qué hacer cuando una página que debería estar indexada no lo está.

Cómo arreglar robots.txt, mapas del sitio y cadenas de redirección

Una vez que sabes qué te indica el informe de indexación de páginas, las soluciones reales suelen estar en tres lugares: el archivo robots.txt, el mapa del sitio y cualquier redirección encadenada en el sitio.

Revisar robots.txt por bloqueos accidentales

Abre el archivo robots.txt de tu sitio directamente, normalmente en la raíz del dominio, y lee cada regla. Una sola línea pensada para bloquear una carpeta de administración o un subdominio de pruebas puede capturar por accidente un directorio entero de páginas reales si está escrita de forma demasiado amplia.

El Robots.txt Checker gratuito de RepGet ofrece un veredicto claro sobre qué está bloqueado para los buscadores y los bots de IA a la vez, lo cual es más rápido que leer la sintaxis en bruto línea por línea. Nuestra guía del generador de robots.txt explica cómo crear un archivo seguro desde cero si el existente necesita reescribirse y no solo recortarse.

Mantener el mapa del sitio sincronizado con las páginas reales

Un mapa del sitio XML solo es útil si enumera las páginas que realmente existen y devuelven un estado 200 normal. Un mapa que sigue listando páginas eliminadas hace meses, o que no incluye páginas añadidas desde su última generación, envía a Google señales contradictorias sobre qué está vigente en el sitio.

El Sitemap Checker & Finder gratuito de RepGet encuentra y valida el mapa del sitio de una web, y marca las URL que no se resuelven como deberían. La mayoría de las plataformas web regeneran el mapa automáticamente, pero conviene confirmar que realmente ocurre en lugar de darlo por hecho.

Detectar y corregir cadenas de redirección

Una cadena de redirección se produce cuando una URL redirige a una segunda, que redirige a una tercera, en lugar de apuntar directamente a la página final. Cada salto adicional suma tiempo de carga y le da a Google un lugar más donde algo puede fallar.

Estas cadenas se acumulan en silencio durante años, normalmente después de que un sitio haya sido rediseñado más de una vez sin que nadie limpie las redirecciones antiguas que quedaron. Para encontrarlas, revisa tus páginas con más enlaces, traza adónde lleva realmente cada redirección y reapunta directamente a su destino final cualquier enlace con más de un salto.

Velocidad del sitio y Core Web Vitals: qué es realmente un factor de posicionamiento

La velocidad de página recibe mucha atención en las auditorías técnicas, en parte porque se puede medir y en parte porque los sitios lentos son realmente comunes. Lo que conviene aclarar es qué métricas de velocidad documenta Google como señal de posicionamiento y cuáles son simplemente buenas prácticas.

Las tres métricas de Core Web Vitals, explicadas en lenguaje sencillo

Core Web Vitals, documentadas en web.dev, miden tres aspectos de la experiencia de carga de una página. Largest Contentful Paint (LCP) mide cuánto tarda en aparecer el elemento visible más grande, normalmente una imagen o un bloque de texto. Interaction to Next Paint (INP) mide qué tan rápido responde la página cuando alguien hace clic o toca algo. Cumulative Layout Shift (CLS) mide si los elementos se mueven de forma inesperada mientras la página todavía se está cargando.

Qué es una señal de posicionamiento documentada y qué es un consejo general de velocidad

Google ha documentado Core Web Vitals como parte de sus señales de experiencia de página. Eso es distinto de muchos de los consejos de velocidad que circulan en internet, como comprimir cada imagen hasta el tamaño de archivo más pequeño posible o perseguir una puntuación perfecta de 100 en una herramienta de prueba de velocidad, algo que va bastante más allá de lo que Google mide realmente.

Una página que cumple los umbrales de Core Web Vitals ha alcanzado el estándar documentado. Ganar otro medio segundo por encima de eso a veces vale la pena para los visitantes, pero no es una ventaja de posicionamiento documentada frente a una página que ya cumple.

Revisar las puntuaciones de tu propio sitio

El informe de Core Web Vitals de Search Console muestra cómo están funcionando realmente tus páginas con visitantes reales, agrupadas según si aprueban, necesitan mejorar o no cumplen cada métrica. Es una lectura más fiable de tu sitio que una sola prueba desde una ubicación y un dispositivo concretos, ya que refleja las condiciones reales de tus visitantes.

Para una comprobación rápida de una página concreta, una herramienta dedicada a probar la velocidad puede mostrar qué elementos específicos la ralentizan, como una imagen principal demasiado pesada o un script que se carga antes del contenido que afecta. En cualquier caso, el objetivo no es una puntuación perfecta. Es que cada página importante supere los umbrales documentados.

Renderizado móvil: lo que ve Google en un teléfono frente a lo que ves tú

Una página que se ve bien en el monitor de un ordenador puede comportarse de forma muy distinta en la pantalla de un teléfono, y en la mayoría de los sitios de hoy, la versión para móvil es la que cuenta.

Por qué la indexación mobile-first cambia lo que cuenta

Google ha documentado que utiliza principalmente la versión móvil del contenido de una página para la indexación y el posicionamiento, una práctica que llama indexación mobile-first. Eso significa que la versión de tu página que Google evalúa con más atención no es necesariamente la que ves cuando revisas tu sitio en un portátil.

Si una versión de escritorio oculta un bloque de texto en el móvil, o carga contenido extra solo después de un clic que un visitante del teléfono nunca hace, la visión principal que Google tiene de esa página no incluye lo que no llegó a la versión móvil. Una auditoría SEO técnica que solo revisa el sitio en escritorio está comprobando la copia equivocada de la página.

Problemas comunes de renderizado móvil en sitios de pequeños negocios

Algunos problemas de usabilidad móvil aparecen una y otra vez en los sitios de pequeños negocios. El texto que se lee bien en escritorio se encoge hasta un tamaño incómodo en el teléfono, y obliga a los visitantes a pellizcar y ampliar. Los botones y enlaces están tan juntos que un toque en uno activa otro sin querer.

Un popup a pantalla completa que tapa la página antes de que el visitante haya leído nada es otro error frecuente, sobre todo en sitios creados con una plantilla que lo activa por defecto. Y un menú de navegación pensado para el ratón a veces directamente no se abre en una pantalla táctil, lo que deja al visitante sin acceso al resto del sitio.

Cómo probar la versión móvil de tu sitio

La prueba más directa es abrir tu sitio en un teléfono real, con datos móviles y no con wifi, y usarlo como lo haría un visitante: pulsar el menú, leer el párrafo principal, intentar llegar a tu página de contacto. Fíjate en cualquier cosa que resulte apretada, oculta o que no responda.

Nuestra guía sobre cómo ver tu sitio web como Googlebot explica una forma más técnica de comprobar lo que el rastreador de Google realmente ve cuando renderiza una página, que va un paso más allá de revisar el diseño visual por tu cuenta.

Datos estructurados y schema: lo que aporta (y lo que no)

El marcado schema es uno de los elementos más malinterpretados en un informe de auditoría técnica, en parte porque suena más poderoso de lo que realmente es.

Qué hace realmente el schema por una página

El schema es una forma estandarizada de etiquetar la información de una página para que un programa informático pueda leerla con fiabilidad, en lugar de adivinarla a partir de un bloque de texto normal. La documentación de Google sobre datos estructurados explica que puede hacer que una página sea apta para ciertas funciones enriquecidas en los resultados de búsqueda, como las valoraciones con estrellas o un desplegable de preguntas frecuentes, pero no mejora directamente la posición de la página en el ranking.

Esa distinción importa. Una página con un schema perfecto y un contenido flojo y genérico no superará a una página sin schema y con textos realmente útiles. El schema es una capa de presentación que se sitúa encima de un contenido que, por sí mismo, tiene que ser bueno.

Tipos de schema que merece la pena añadir en un pequeño negocio

La mayoría de los pequeños negocios no necesitan una configuración de schema extensa. Unos pocos tipos cubren las situaciones que realmente se presentan, y schema documenta el vocabulario completo por si alguna vez hace falta un tipo más específico.

Validar el marcado antes de publicarlo

El schema escrito de forma incorrecta, incluso con un pequeño error de sintaxis, a menudo falla en silencio en lugar de mostrar un error evidente en la propia página. Un validador comprueba que el marcado esté estructurado como espera el vocabulario del schema antes de publicarlo, lo que detecta errores que de otro modo pasarían inadvertidos durante meses.

Search Console también informa de errores de datos estructurados en las páginas que ya ha rastreado, lo que conviene revisar periódicamente incluso después de que el marcado lleve activo un tiempo, ya que una actualización del sitio puede romperlo sin que nadie lo note.

Ordenar los problemas técnicos por impacto y esfuerzo

Con las cuatro áreas ya cubiertas, la siguiente pregunta es en qué orden trabajar un informe de auditoría real, sobre todo si mezcla problemas de más de una de estas categorías a la vez.

Por qué los errores de rastreo e indexación van primero

Una página bloqueada o no indexada supera a todo lo demás de esta lista, porque nada más importa hasta que se corrige. Una mejora de velocidad en una página que Google no puede leer es esfuerzo desperdiciado, y lo mismo ocurre con añadir schema a una página que ni siquiera está en el índice.

Por eso el orden de este artículo no es arbitrario. Los errores de rastreo van primero porque pueden hacer inútil cualquier otra corrección. La velocidad y el renderizado móvil vienen después porque afectan a páginas que Google ya puede ver y posicionar, solo que no tan bien como podrían. El schema va al final porque añade valor de presentación sobre una página que ya funciona.

Dónde encajan la velocidad, el móvil y el schema después de eso

Una vez resuelto el rastreo, los problemas de velocidad y de móvil suelen merecer el siguiente lugar, ya que ambos están documentados como parte de cómo Google valora la experiencia de página y ambos afectan a cada visitante que llega a la página, no solo a los que Google rastrea. El schema encaja después, como una adición que merece la pena pero de menor prioridad.

La misma lógica de esfuerzo frente a impacto que se aplica a cualquier lista de auditoría vale aquí también. Una página bloqueada requiere poco esfuerzo y tiene mucho impacto, así que siempre merece la pena arreglarla primero, independientemente de lo que haya en la lista. Una página lenta y con muchas imágenes exige más trabajo, pero sigue importando. Que falte el texto alternativo en unas pocas imágenes es rápido de corregir pero menor. Y una página de archivo poco visitada y enterrada en lo profundo del sitio normalmente no vale la pena el tiempo que cuesta.

Matriz 2x2 que ordena los problemas de auditoría SEO técnica por esfuerzo e impacto, con ejemplos en cada cuadrante: una página importante bloqueada como victoria rápida, páginas lentas con muchas imágenes como un proyecto más grande, el texto alternativo que falta como rápido pero menor, y una página de archivo poco visitada que se puede dejar para más adelante.

Un caso práctico: auditoría de un pequeño negocio

Imagina que una pequeña empresa de jardinería realiza por primera vez en varios años una auditoría técnica de su sitio. Este ejemplo es ilustrativo.

Qué cambió y en qué orden

La auditoría detecta cuatro problemas que abarcan las cuatro áreas tratadas en este artículo: una página de servicio bloqueada por accidente en robots.txt, una página de inicio cargada de imágenes grandes sin comprimir, un menú móvil que no se abría en una pantalla táctil y ningún marcado schema en todo el sitio. Al trabajar en ellos en el orden que recomienda este artículo, el proceso queda así.

Estas cifras son ilustrativas.

La página bloqueada se corrigió primero, ya que nada más importaba hasta que Google pudiera leerla de verdad. La velocidad y el móvil vinieron a continuación, porque ambas afectaban a visitantes reales y forman parte de cómo Google documenta la experiencia de página. El schema fue lo último, añadido una vez que todo lo que había debajo ya funcionaba.

Una revisión técnica semanal de 20 minutos

Una auditoría SEO técnica completa no hace falta repetirla cada semana, pero una revisión corta evita que los problemas pequeños se conviertan en los que solo aparecen meses después como una caída de tráfico.

Qué revisar cada semana

Empieza por el informe de Indexación de páginas en Search Console y busca cualquier novedad en la columna de no indexadas. Una página que estaba bien la semana pasada y que esta semana está bloqueada o da errores suele indicar un cambio reciente en alguna parte de la web, y es mucho más fácil rastrearlo mientras todavía está fresco.

A continuación, echa un vistazo al informe de Core Web Vitals por si alguna métrica ha pasado de aprobada a necesita mejora. Basta con una imagen o un script nuevo añadido sin redimensionar para que una página supere el umbral documentado, y detectarlo pronto significa una corrección de cinco minutos en lugar de una investigación más lenta después.

Por último, revisa si hay nuevos avisos de usabilidad móvil y cualquier error de datos estructurados que Search Console haya empezado a reportar. Ambos suelen aparecer tras una actualización del tema, un cambio de plugin o un rediseño, incluso pequeño, y ambos son mucho más rápidos de corregir la semana en que aparecen que tres meses después.

Cómo se ve un problema recurrente

Una página bloqueada o una imagen lenta es una corrección puntual. Un patrón, como que tres páginas distintas pierdan la validación de su schema en el mismo mes, normalmente significa que algo más arriba, una plantilla, un plugin o un cambio reciente en la web, está causándolo una y otra vez, en lugar de que cada caso sea un accidente independiente.

Detectar ese patrón durante la revisión semanal, en lugar de descubrirlo en una auditoría anual, es el verdadero valor de mantener esta rutina breve y regular en vez de saltársela hasta que algo se rompe a simple vista.

Errores comunes en una auditoría SEO técnica

Algunos hábitos anulan con frecuencia el valor de una auditoría técnica hecha con cuidado, y la mayoría surgen de trabajar un informe en el orden equivocado o de perseguir el número equivocado.

Corregir el schema antes que un bloqueo de rastreo es uno de los más comunes. Dedicar una tarde a añadir marcado de preguntas frecuentes a una página bloqueada en robots.txt hace que ese marcado no sirva de nada hasta que se elimine el bloqueo de fondo, por lo que el orden en que se hace importa más que la calidad del trabajo en sí.

Perseguir una puntuación de velocidad perfecta es otro. Una página que ya supera los umbrales documentados de Core Web Vitals no gana una ventaja de posicionamiento adicional por ganar una décima de segundo más, aunque una puntuación de 100 sobre 100 en una herramienta de pruebas pueda hacer que parezca válido intentarlo de todos modos.

Omitir las pruebas específicas para móvil, y revisar solo una ventana de escritorio del navegador reducida, deja pasar problemas reales. Un navegador redimensionado no reproduce una pantalla táctil, una conexión móvil más lenta ni la forma en que el sistema operativo del teléfono muestra las fuentes, así que los problemas que solo aparecen en un dispositivo real pasan desapercibidos.

No volver a comprobar tras publicar las correcciones completa la lista. Una corrección que no llegó a guardarse, o que una modificación posterior sobrescribió, puede seguir rota durante meses si nadie vuelve a mirar para confirmar que funciona.

Dónde encaja RepGet

La mayor parte de este artículo es trabajo que puedes hacer con Search Console y un teléfono en la mano, pero una primera pasada por todo un sitio avanza más rápido con una herramienta pensada para ello. La auditoría web gratuita de RepGet rastrea un sitio y le asigna una puntuación SEO de 0 a 100, señalando problemas técnicos que conviene investigar junto con los de contenido, incluidos varios de los que trata este artículo: si las páginas son accesibles e indexadas, y problemas básicos de experiencia de página. Es un punto de partida razonable para ver cómo está un sitio en gran parte de esta lista de una vez. No se requiere cuenta ni tarjeta de crédito.

RepGet no sustituye los propios informes de Indexación de páginas y Core Web Vitals de Search Console, que se nutren de datos de visitantes reales que un rastreo puntual no puede ver. Tampoco sustituye el criterio necesario para decidir qué corrección importa más a tu sitio específico esta semana, ni garantiza un posicionamiento, una posición en Google Maps o un resultado de tráfico gracias a cualquier corrección técnica, por cuidadosamente que se haga.

En resumen

Una auditoría SEO técnica solo necesita cubrir cuatro cosas en la mayoría de webs de pequeños negocios: si Google puede rastrear e indexar tus páginas, qué velocidad tienen al cargar, cómo se muestran en un teléfono y si tus datos estructurados son válidos.

Seguir ese orden importa más que recorrer los cuarenta puntos que un informe largo pueda marcar. Una página bloqueada anula todo lo demás de la lista, así que va primero. La velocidad y el móvil afectan a cada visitante real, así que vienen después. El schema aporta valor sobre una página que ya funciona, así que va al final.

Ninguna auditoría, por completa que sea, puede prometer en qué posición aparecerá una página en los resultados de búsqueda una vez hechas las correcciones. Lo que sí puede hacer es asegurarse de que Google está viendo la mejor versión de tu sitio, en lugar de adivinarla a partir de una versión con problemas que nadie detectó.

Averigua primero lo que necesita tu web

Antes de repasar a mano una lista larga de incidencias, mira en qué punto está realmente tu sitio. Ejecuta una auditoría web gratuita con RepGet para comprobar el rastreo, la indexación y la experiencia básica de página junto con tu contenido. No se requiere cuenta ni tarjeta de crédito.