Auditoría técnica del sitio web: qué corregir antes de probar otro truco de SEO

Un sitio web puede tener un diseño atractivo, un círculo verde en su plugin de SEO y aun así perder visitantes antes de que se haya cargado el contenido principal. O Google puede indexar una URL distinta de la que esperas. O un pedido puede funcionar, pero la medición enviarlo dos veces.

Por eso no empiezo una auditoría técnica persiguiendo una puntuación de cien en una sola prueba. Primero busco errores que impidan el funcionamiento del negocio, la indexación o el uso del sitio web. Solo después pulo los pequeños detalles.

1. Verifica que las URL importantes devuelvan el estado correcto

Revisa las páginas principales de servicios, los artículos que reciben tráfico, la página de contacto y la ruta de conversión. Una página importante debería devolver 200. El contenido trasladado permanentemente debería tener una única redirección directa 301. Una página eliminada no debería acabar silenciosamente en la página de inicio.

También compruebo las variantes HTTP y HTTPS, con www y sin www, las barras finales y los parámetros. El resultado debería ser una única URL canónica. Google describe una redirección como una señal fuerte de canonicalización y recomienda combinarla con una canónica y un sitemap coherentes en su documentación sobre URL canónicas.

2. Comprueba la indexación desde la perspectiva de la página real

Robots.txt, los meta robots, la canónica y el sitemap deben funcionar juntos. Un error común es indexar una página que no tiene cabida en las búsquedas mientras se bloquea contenido importante. Utiliza la inspección de URL en Search Console para varias URL representativas. Muestra lo que Google sabe sobre la página y permite probar la versión publicada.

  • ¿La URL canónica es la que quieres?
  • ¿La página está disponible sin iniciar sesión ni bloqueos?
  • ¿El mapa del sitio contiene únicamente 200 URL indexables?
  • ¿Los enlaces internos evitan las redirecciones?
  • ¿Hay páginas importantes sin enlaces que apunten a ellas?

Google mantiene una visión general de estas áreas en su documentación sobre rastreo e indexación.

3. Mide la velocidad en personas, no solo en laboratorio

PageSpeed Insights y Lighthouse son herramientas de diagnóstico útiles. Pero una prueba de laboratorio no es lo mismo que la experiencia de los visitantes reales. Los Core Web Vitals actuales son LCP, INP y CLS; los datos de campo trabajan con dispositivos y conexiones reales. La documentación oficial sobre Web Vitals explica la visión general y la diferencia entre los datos de campo y de laboratorio.

Yo interpretaría las prioridades así:

  1. LCP: cuándo aparece el contenido principal.
  2. INP: con qué rapidez responde la página al uso.
  3. CLS: si los elementos saltan mientras se carga la página.
  4. TTFB y red: si empieza a ocurrir algo rápidamente.

Google también dice explícitamente que una buena puntuación no garantiza las primeras posiciones. La usabilidad general importa más que perseguir un único número. Consulta la documentación sobre la experiencia en la página.

4. Encuentra al verdadero culpable de la carga

En la cascada de carga y DevTools, busca un tiempo de servidor elevado, CSS y JavaScript que bloqueen la carga, imágenes demasiado grandes, fuentes, solicitudes repetidas y servicios de terceros. La antigua regla de «combinar todos los archivos» ya no es universal. Con los protocolos modernos, la cantidad de código sin utilizar y el bloqueo del hilo principal pueden importar más.

  • Carga la imagen principal con un tamaño adecuado y en un formato moderno.
  • Define las dimensiones de las imágenes para que no desplacen el contenido.
  • El contenido que queda por debajo de la primera ventana gráfica puede usar carga diferida nativa.
  • Carga únicamente los pesos y conjuntos de caracteres necesarios de cada fuente.
  • Carga los scripts de marketing de forma asíncrona y solo donde tengan una finalidad.
  • Comprime los recursos de texto y establece una caché larga para los archivos versionados.

Un servicio de terceros cuesta más que unos milisegundos. Cada píxel, widget de chat y mapa de calor crea más responsabilidad operativa y de datos. Si nadie utiliza el informe, elimina el script.

5. Recorre el sitio web como cliente con un teclado y un móvil

En el móvil, recorre la navegación, el formulario, el diálogo de cookies y el pedido. Amplía el texto y desactiva las imágenes; utiliza un teclado. Los encabezados deben formar una estructura comprensible, un formulario necesita etiquetas y un mensaje de error debe indicar qué hay que corregir.

Cada página debería tener una tarea principal. Eso no significa poner un botón a cualquier precio, sino establecer una jerarquía clara. Encuentra más puntos prácticos en la lista básica de comprobación de UX.

6. Corrige los errores de recursos y JavaScript

Un 404 en una imagen, fuente o script no es un detalle estético. Puede romper la apariencia, la medición o la funcionalidad. Comprueba los errores de la consola del navegador, las solicitudes de red fallidas y las respuestas 5xx repetidas del servidor. Prueba los recorridos críticos después de cada publicación.

7. Utiliza datos estructurados únicamente para contenido veraz

Schema no es una forma de forzar valoraciones con estrellas. Es una descripción legible por máquinas de lo que realmente aparece en la página. Utiliza un tipo compatible y pruébalo en la prueba de resultados enriquecidos. Google incluye los formatos compatibles y las herramientas de prueba actuales en su documentación sobre datos estructurados.

8. La medición no debe romper el sitio web que pretende medir

Carga GA4, las plataformas publicitarias y otros scripts de forma no bloqueante. Nombra los eventos según las decisiones, no cada clic. Verifica los duplicados, el consentimiento y si alguien utiliza realmente los datos. Encuentra una base práctica en los artículos sobre Google Tag Manager y Google Analytics 4.

9. El dinero y el riesgo determinan el orden de las correcciones

  1. Un pedido, formulario o inicio de sesión que no funciona.
  2. Una página importante que no está disponible o no se puede indexar.
  3. Un problema de seguridad y componentes obsoletos.
  4. Problemas importantes de usabilidad móvil y Core Web Vitals.
  5. Errores de medición que conducen a malas decisiones.
  6. Solo después, puntuaciones menores y problemas estéticos.

El SEO técnico es la línea de salida. No gana la carrera por sí solo, pero un sitio web roto puede perderla antes del pistoletazo. Si necesitas convertir los hallazgos técnicos en prioridades de negocio, puedes describir el sitio web y la decisión a la que te enfrentas.

¿Necesitas claridad en marketing?

Primero, aclaremos la situación.

Si tu empresa se enfrenta a una decisión similar, envíame brevemente el contexto. Veremos si tiene sentido continuar.

Describe la situación