
Lista de verificación técnica de SEO
Rastreo e indexación
Lo primero que debe observar durante la auditoría técnica es cómo los motores de búsqueda indexan y rastrean su sitio. Después de todo, si las páginas de su sitio no se pueden rastrear, no se indexarán (con pocas excepciones). Como consecuencia, las páginas no representadas en el índice no participarán en el ranking.
Revise el informe de indexación de páginas en Google Search Console
La forma más precisa y fiable de analizar la indexación de tu sitio web es analizar el Informe de Indexación de Páginas en Google Search Console.
Mira el informe de páginas indexadas y comprueba qué páginas están en el índice. Vea si hay páginas con opciones de filtrado u ordenación, si hay páginas de prueba u otras páginas que no desea indexar.
Además, mire las páginas que han sido excluidas.
No todos los estados del informe de páginas excluidas son un problema. No debe centrar su atención en todas las páginas excluidas, sino solo en aquellas en las que el comportamiento de Google no coincide con sus intenciones.
En la siguiente tabla, puede ver los estados que tienden a requerir atención y un análisis más profundo:
| Estado | Qué significa | Lo que debe hacer |
|---|---|---|
| Error de redireccionamiento | Google no pudo seguir la URL debido a problemas de redireccionamiento. |
|
| Error del servidor | El servidor devolvió un error 5xx. |
|
| Descubierto: no indexado | Google conoce la página, pero aún no la ha rastreado. Indica problemas con el presupuesto de rastreo. |
|
| Rastreado: no indexado | Google visitó la página pero decidió no indexarla. Por lo general, indica una baja calidad de página. |
|
| Duplicar sin canónica seleccionada por el usuario | Google considera que la página está duplicada, pero no especificaste una canónica. |
|
| Duplicado, Google eligió canónico diferente al usuario | Google ignoró su canónica especificada. |
|
| Suave 404 | La página aparece «vacía» o «no encontrada», pero devuelve un estado 200 OK. |
|
Los otros estados probablemente no indiquen ningún problema. Sin embargo, también vale la pena revisar estos informes para asegurarse de que las páginas no hayan sido eliminadas, redirigidas, canonicalizadas o bloqueadas para su indexación por error.
| Estado | Lo que significa | Lo que necesita saber |
|---|---|---|
| Página alternativa con la etiqueta canónica adecuada | Google reconoció correctamente el canónico que especificaste. |
|
| URL bloqueada por robots.txt | Google no puede rastrear la página. |
|
| URL marcada como ‘noindex’ | La página tiene la directiva noindex. |
|
| No encontrado (404) | La página no existe. |
|
| Bloqueado debido a una solicitud no autorizada (401)/ Bloqueado debido a un acceso prohibido (403) | La página está bloqueada por autorización o prohibida. |
|
| Página con redirección | La página redirige a otra. |
|
| URL bloqueada debido a otro problema 4xx | La página es inaccesible debido a un error 4xx que no sea 404 (por ejemplo, 403, 401, 410, etc.). |
|
En el Centro de Ayuda de Google, puedes encontrar una descripción completa del informe de la página, incluidos ejemplos de problemas y una explicación detallada de cada estado.
Screaming Frog también puede ayudar a analizar las páginas indexadas o excluidas del índice. Para hacer esto, debe conectar la API de Google Search Console antes de iniciar el rastreo del sitio.
Para conectarse, vaya a Configuración -> Acceso a la API -> Google Search Console. Haga clic en Iniciar sesión con Google y siga las instrucciones.

Source: Screaming Frog
Una vez conectado, habilite la inspección de URL y también puede habilitar la opción de omitir la inspección de indexación para las URL que no se pueden indexar.

Source: Screaming Frog
A continuación, podrá ver y comparar el estado de cada página según Search Console (la forma en que Google la ve) y su estado real determinado durante el proceso de rastreo.

Source: Screaming Frog
Tenga en cuenta que solo hay 2000 URL por día disponibles para cada sitio, por lo que este método es más adecuado para sitios pequeños.
Comprueba lo que hay en tu sitemap.xml
Sitemap.xml es un archivo XML que proporciona a los rastreadores de los motores de búsqueda una lista de páginas de un sitio, así como (opcionalmente) información sobre su fecha de última modificación, frecuencia de actualización y prioridad de rastreo recomendada.
Por lo general, se coloca en la raíz del sitio, por ejemplo: https://example.com/sitemap.xml. Sitemap.xml ayuda a los motores de búsqueda a encontrar páginas nuevas o actualizadas más rápido. Además, la inclusión de una página en este archivo es una de las señales para determinar la versión canónica de una página, aunque sea débil.

Source: e-commerce sport store
El archivo sitemap.xml es especialmente útil para:
- nuevos sitios con pocos enlaces externos;
- sitios grandes con muchas páginas;
- sitios con mucho contenido multimedia;
- sitios de noticias que se actualizan con frecuencia.
Sitemap.xml debe contener todas las páginas que desea indexar.
Puede usar el mismo Screaming Frog u otros rastreadores para analizar las páginas incluidas en Sitemap.xml. En Screaming Frog, sitemap.xml se puede escanear por separado en el modo de lista, o se puede incluir en un escaneo normal del sitio. Para ello, en Configuración -> Spider -> Crawl, active el escaneo de mapas del sitio XML y agregue las URL absolutas de los mapas del sitio que desea rastrear.
No se recomienda utilizar varios servicios en línea para generar un mapa del sitio, ya que solo pueden generar un mapa del sitio estático que no se actualizará automáticamente. La opción óptima es generar el sitemap.xml utilizando complementos para el CMS en el que se ejecuta el sitio, o escribir un script personalizado que genere el mapa del sitio de acuerdo con las condiciones especificadas y lo actualice automáticamente cuando se realicen cambios en el sitio.
Al generar el sitemap.xml, asegúrese de que su archivo cumpla con el protocolo sitemap.xml. Para ello, puede utilizar varios validadores en línea, como https://www.xml-sitemaps.com/validate-xml-sitemap.html.
¿Es necesario incluir todas las etiquetas enumeradas en el protocolo? No siempre. Por ejemplo, Google solo considera las etiquetas <loc> y <lastmod>. Asegúrese de que la fecha en la etiqueta <lastmod> sea correcta. Si hay intentos de manipularlo, Google puede ignorar esta etiqueta.
Asegúrese de que no haya errores en robots.txt
El archivo robots.txt es el primer lugar donde busca un bot de búsqueda antes de rastrear un sitio. Determina qué secciones del sitio se pueden o no rastrear y, como resultado, qué páginas serán indexadas por los motores de búsqueda. Siempre debe estar ubicado en https://example.com/robots.txt.
Este archivo es una herramienta para administrar el rastreo (¡no la indexación!) del sitio. Algunas páginas, incluso si están bloqueadas en robots.txt, aún se pueden indexar (generalmente si hay enlaces internos o externos a ellas). Dichas páginas (indexadas a pesar de estar bloqueadas en robots.txt) se pueden ver en Google Search Console en el informe «Indexadas, aunque bloqueadas por robots.txt».

Source: Search Console
Esto es lo que debe asegurarse de verificar con respecto al archivo robots.txt como parte de una auditoría técnica de SEO:
- Disponibilidad del archivo
El archivo debe ser accesible en https://example.com/robots.txt y dar un estado de respuesta 200 OK. Su ausencia, errores de descarga o redireccionamientos (301, 302, 403, 404) pueden impedir que los motores de búsqueda comprendan correctamente las reglas de rastreo del sitio.
- Sintaxis y corrección
Compruebe que la estructura de archivos sigue el estándar. Ejemplo de una plantilla básica:
- Agente de usuario: *
- No permitir: /admin/
- Permitir: /público/
- Mapa del sitio: https://example.com/sitemap.xml

Source: nike.com
- Directivas Disallow y Allow
Comprueba que las páginas importantes no se rechazan accidentalmente, por ejemplo:
- Inicio (/)
- Fichas de producto (/product/)
- Blog o artículos (/blog/, /artículos/)
Un error común es bloquear imágenes, estilos y scripts al bloquear carpetas administrativas. En tal caso, se debe especificar que, aunque la carpeta administrativa está bloqueada, algunos tipos de archivos deben estar abiertos para escanear. Esto sucede a menudo en los sitios de WordPress cuando la carpeta con todo el contenido del usuario, Disallow: /wp-content está bloqueada.
En este caso, solo se pueden abrir archivos de un formato determinado para escanear:
- Permitir: /wp-content/uploads/*.css
- Permitir: /wp-content/uploads/*.js
- Permitir: /wp-content/uploads/*.jpeg
Para validar su robots.txt y probar las directivas que va a agregar, puede usar esta herramienta.
- Comprobar la compatibilidad con otras directivas
Los errores a menudo ocurren cuando robots.txt entra en conflicto con:
- meta etiqueta <meta name=»robots» content=»noindex»>
- canónico
Por ejemplo, si una página está abierta en robots.txt pero bloqueada a través de noindex, se rastreará, pero no entrará en el índice. Esto es aceptable, pero es importante que se haga intencionalmente.
Además, un problema común es cuando hay otras instrucciones para bots en el código fuente y un bloqueo simultáneo de la página en robots.txt. Los robots de los motores de búsqueda no escanean las páginas bloqueadas en robots.txt. No ven las etiquetas especificadas en el código, por ejemplo, canonicalización. Es decir, tal canónica simplemente no se tendrá en cuenta.
Revisa tus enlaces internos
Una de las tareas clave de una auditoría técnica es garantizar que los enlaces internos del sitio funcionen correctamente. Esto significa que todos los enlaces internos deben conducir a páginas reales y existentes que estén abiertas para la indexación, devuelvan un código de estado 200 OK, no contengan redirecciones y, lo más importante, no apunten a páginas con errores 4xx/5xx. A primera vista, esto puede parecer un detalle menor, pero en la práctica, incluso los enlaces internos incorrectos pueden afectar negativamente:
- La eficiencia del rastreo de sitios web por parte de los motores de búsqueda,
- La distribución del peso interno de SEO (PageRank),
- Experiencia de usuario.
El primer paso en el análisis es verificar todos los enlaces internos en busca de errores. Es especialmente importante identificar los enlaces rotos que conducen a páginas con un 404, 410 u otros errores (como 403, 500).
A continuación se muestra una tabla con los principales tipos de errores que pueden ocurrir en los enlaces internos, su significado y las acciones recomendadas para solucionarlos.
| Tipo de error | Qué significa | Qué hacer |
|---|---|---|
| 404 | Página no encontrada | Retire el enlace o reemplácelo por uno que funcione |
| 403 | Acceso prohibido | Comprobar la configuración de acceso |
| 301/302 | Redirigir | Actualizar el enlace a la URL final |
| 5xx | Error del servidor | Verifique el servidor o CMS |
También es importante analizar la profundidad de la jerarquía de la página, es decir, determinar en qué nivel y a cuántos clics de la página de inicio se encuentra el contenido clave. Es preferible que las páginas importantes no sean más profundas que el tercer nivel , lo que aumenta su accesibilidad tanto para los motores de búsqueda como para los usuarios.
Uno de los elementos clave del análisis es identificar las páginas «huérfanas», aquellas que no tienen enlaces internos que apunten a ellas. Incluso si estas páginas están incluidas en el mapa del sitio, la falta de enlaces internos las hace menos accesibles.
Además, es importante analizar los textos de anclaje: las palabras y frases que contienen enlaces. Deben ser relevantes y significativos, ya que los textos de anclaje ayudan a los motores de búsqueda a comprender el contexto del enlace.
Análisis de las estadísticas de rastreo
El análisis de estadísticas de rastreo es una forma de comprender cómo interactúa Googlebot con un sitio: qué páginas se rastrean, con qué frecuencia y cómo esto afecta al SEO. Estos datos están disponibles en Configuración → de Google Search Console → Estadísticas de rastreo. En la siguiente tabla, puede ver los problemas más comunes que puede encontrar en este informe:
| Problema | Qué buscar en el informe | Posibles causas |
|---|---|---|
| Fuerte disminución del gateo | Menos rastreos por día | Problemas de accesibilidad, configuración incorrecta en robots.txt, bloqueos, errores 5xx |
| Muchos errores 4xx y 5xx | Errores en las URL | Páginas eliminadas, enlaces rotos, problemas con el servidor |
| Aumento del tiempo de respuesta | >1 segundo: una señal de advertencia | Problemas de hosting, sobrecarga del servidor |
| Muchos redireccionamientos 3xx | Redirecciones en lugar de URL directas | Redirecciones incorrectas, cadenas de redirecciones, una gran cantidad de enlaces internos con redirecciones |
| CSS/JS no rastreado | Faltan en las estadísticas | Bloqueado por robots.txt |
Además, se pueden analizar los registros del servidor. Le permiten ver las solicitudes reales de los robots de búsqueda (no solo Googlebot sino también Bingbot, YandexBot y otros), en lugar de solo datos agregados de Google Search Console.
Este es un método de diagnóstico avanzado y «crudo» que requiere una cantidad significativa de tiempo. Para visualizar los datos, puede utilizar herramientas de código abierto como GoAccess o Screaming Frog Log File Analyser.
Implementar datos estructurados
Los datos estructurados son un formato de marcado especial en una página web que ayuda a los motores de búsqueda a comprender el contenido de la página de manera más precisa y profunda. Sirve como una «pista» para Google y otros motores de búsqueda sobre qué hay exactamente en la página: un artículo, producto, receta, reseña, video, etc. Si bien no es una señal de clasificación oficial, afecta indirectamente las clasificaciones al mejorar la forma en que los motores de búsqueda entienden la página.
El principal estándar o protocolo utilizado para los datos estructurados en los sitios web es Schema.org. Existen otros protocolos, como OpenGraph, pero se utiliza para redes sociales.
Schema.org es un proyecto colaborativo de Google, Microsoft, Yahoo y Yandex, creado para desarrollar y mantener un estándar unificado para datos estructurados en la web.
Schema.org incluye cientos de tipos de entidades, y los más utilizados se enumeran en la siguiente tabla:
| Categoría | Entidad (@type) | Propósito |
|---|---|---|
| Contenido y páginas | Artículo | Un artículo o contenido de noticias |
| Publicación de blog | Una publicación de blog | |
| NoticiasArtículo | Un artículo de noticias para Google Noticias | |
| FAQPage | Una página de preguntas frecuentes (FAQ) | |
| Cómo hacerlo | Una guía paso a paso | |
| Página web | Información general sobre una página web | |
| Productos y ofertas | Producto | Descripción del producto |
| Ofrecer | Oferta de precio | |
| Oferta agregada | Rango de precios para un producto de diferentes vendedores | |
| Reseñas y calificaciones | Revisión | Una reseña de un producto o servicio |
| Clasificación | Una calificación numérica (a menudo dentro de una Reseña) | |
| Calificación agregada | Calificación promedio basada en múltiples reseñas | |
| Organizaciones y Personas | Organización | Una descripción de una empresa o marca |
| Negocio local | Un negocio local con información de contacto y horario | |
| Persona | Una persona (por ejemplo, autor del artículo, orador, etc.) | |
| Eventos | Evento | Un evento online u offline |
| Navegación y estructura | Lista de migas de pan | Navegación de migas de pan |
| Elemento SiteNavigationElement | Elementos del menú principal | |
| Multimedia | VideoObjeto | Vídeo con metadatos (para fragmentos de vídeo) |
| Objeto de imagen | Imagen con descripción | |
| Educación y Empleo | Curso | Un curso o programa de formación en línea |
| Publicación de empleo | Oferta de empleo (para Google for Jobs) |
Se recomienda implementar datos estructurados en formato JSON-LD. Este bloque se coloca en el <cabeza> o <cuerpo> del documento HTML, pero no se muestra al usuario, sino que es leído por los robots de búsqueda. Todos los principales motores de búsqueda, como Google, Bing y Yahoo, admiten este formato. A continuación se muestra un ejemplo de código JSON-LD:
<script type=»application/ld+json»>
{
«@context»: «https://schema.org»,
«@type»: «Artículo»,
«headline»: «¿Qué es JSON-LD?»,
«autor»: {
«@type»: «Persona»,
«nombre»: «Juan Smith»
},
«fechaPublicado»: «2025-12-01»
}
</script>
Al implementar datos estructurados, siga el protocolo Schema.org y utilice el validador para comprobar la exactitud de los tipos de microdatos implementados. Algunos tipos de datos estructurados del protocolo Schema.org también pueden ayudar con la visualización de fragmentos enriquecidos en los resultados de búsqueda de Google.
Ten en cuenta que los requisitos de Google para los datos estructurados para los fragmentos enriquecidos difieren ligeramente del estándar Schema.org. A menudo, es necesario especificar más campos de los que requiere el protocolo Schema.org. Por lo tanto, si desea lograr un fragmento enriquecido, siga las pautas de Google para datos estructurados. Puede comprobar la exactitud de la implementación de microdatos mediante el validador de fragmentos enriquecidos.
También hay muchos generadores de microdatos, pero solo pueden crear código estático que no se actualizará con los cambios de contenido en la página. Garantizar que la información de los microdatos coincida con lo que es visible para los usuarios en la página es parte de los requisitos de Google para los datos estructurados. Si se infringe la política relativa a los datos estructurados, la página puede perder todos los fragmentos enriquecidos y, en algunos casos, enfrentarse a sanciones manuales. Por lo tanto, asegúrese de que sus microdatos se generen y actualicen automáticamente.
Contenido
Como parte de una auditoría técnica de SEO, es importante evaluar las características básicas del contenido: desde la estructura de los encabezados y las metaetiquetas hasta la presencia de atributos alt para las imágenes y las posibles páginas duplicadas. Estos elementos afectan directamente tanto a la indexación como a la forma en que los motores de búsqueda perciben el sitio.
Pruebe su sitio web en busca de duplicados completos
Los duplicados completos se producen cuando se puede acceder a contenido idéntico a través de diferentes URL en el sitio. Los duplicados pueden dañar por completo la clasificación de su sitio.
Los tipos más comunes de duplicados completos son:
- Accesibilidad a través de HTTP y HTTPS
- Accesibilidad con y sin WWW
- Accesibilidad con o sin barra diagonal final
- Accesibilidad de URL en mayúsculas y minúsculas
- Se puede acceder a la página con extensiones de archivo como .html, .htm, .php, .aspx y sin ellas
- Parámetros que no cambian el contenido de la página, como las etiquetas UTM
- Contenido idéntico en diferentes URL. Por ejemplo, un producto se enumera en dos categorías, accesibles a través de dos URL diferentes. O la página del producto accesible con y sin la categoría en la URL.
- Versiones de prueba del sitio (dominio DEV utilizado para el desarrollo).
Para encontrar duplicados de página relacionados con variaciones de URL, pruebe las URL manualmente y verifique el código de respuesta del servidor para esas variantes de URL. Puede utilizar cualquier herramienta para comprobar los códigos de respuesta del servidor, como https://httpstatus.io/. Ingrese las variaciones de URL y verifique su accesibilidad.

Source: httpstatus.io/ website + test of a client’s website
Para solucionar problemas con variaciones en HTTP/HTTPS, www/without-www, con/sin barra, mayúsculas/minúsculas y la accesibilidad de páginas con extensiones como .html, .htm, .php, .aspx, y sin ellas, es necesario configurar una redirección 301 a la versión preferida.
Cuando se encuentran duplicados debido a la disponibilidad de contenido idéntico al agregar o eliminar partes de la URL (por ejemplo, un producto está disponible en dos categorías), es mejor reconsiderar la estructura de URL y la estructura del sitio. Para UTM y otros parámetros, la canonicalización también puede ser una solución. Sin embargo, es importante tener en cuenta que Google trata la etiqueta canónica como una recomendación, y la decisión final sobre qué URL elegir sigue siendo de Google.
Si se encuentra una versión de prueba del sitio en el índice de Google, se debe bloquear la indexación y se debe enviar una solicitud para su eliminación a través de Google Search Console.
Resolver duplicados parciales de páginas
Los duplicados parciales de página ocurren cuando dos o más páginas del sitio contienen contenido muy similar, pero no completamente idéntico. Los tipos más comunes de duplicados parciales son:
- Ordenar páginas
- Filtrar páginas
- Páginas de paginación
- Páginas con productos similares (por ejemplo, los productos difieren solo por el color)
- Varias versiones del sitio en el mismo idioma, pero para diferentes regiones (por ejemplo, tres sitios en inglés para EE. UU., Reino Unido y Australia).
Por supuesto, cada sitio es único, y durante una auditoría técnica, puede identificar otros casos de contenido duplicado que requieren soluciones específicas. Sin embargo, los ejemplos anteriores son los más comunes.
Los duplicados parciales suelen ser encontrados durante el proceso de rastreo del sitio por varios rastreadores. Tendrán parámetros repetitivos y pueden tener el mismo título y H1 que las páginas de categorías principales.
Para eliminar duplicados parciales, no puede configurar una redirección, ya que estas páginas son necesarias para la funcionalidad del sitio. A continuación, discutiremos los métodos para tratar con duplicados parciales.
Ordenar y filtrar páginas
Estas páginas pueden ser bloqueadas para que no se rastreen en el archivo robots.txt, aunque Google puede ignorarlo, especialmente si los enlaces apuntan a estas páginas. Esto ayudará a preservar el presupuesto de rastreo.
También puedes bloquearlas a través de la directiva <meta name=»robots» content=»noindex, nofollow» />, que evitará que estas páginas se indexen, pero no le dirá a Google que no deben rastrearse.
El mejor enfoque en este caso es usar JavaScript para actualizar el contenido de la página cuando el usuario aplica ordenación o filtros, sin generar direcciones URL adicionales y vínculos a páginas de filtrado u ordenación.
Variantes de productos disponibles en diferentes URL
Idealmente, todas las variantes del producto deben combinarse en una página, donde el usuario puede seleccionar el color o tamaño deseado sin cambiar la URL, usando JavaScript. Sin embargo, si se utiliza una página separada para cada variante, se debe especificar un enlace canónico a la página principal del producto. Sin embargo, como se mencionó anteriormente, Google puede ignorar el conjunto canónico del usuario.
Páginas de paginación
Las páginas de paginación no deben bloquearse para que no se indexen. Para asegurarse de que Google considere la primera página de la categoría como la principal:
- Solo incluya la primera página en el archivo sitemap.xml.
- Agregue un enlace a la página principal de la categoría en todas las páginas de paginación.
- Agregue números de página al título y H1 de las páginas de paginación. Por ejemplo, «Camisas blancas – Página 2».
Páginas disponibles en un idioma pero para diferentes regiones
En este caso, se deben usar atributos Hreflang. Se utilizan para indicar a los motores de búsqueda en qué idioma y versión regional de una página web deben mostrar a los usuarios en función de su preferencia de idioma y ubicación.
Hay varias formas de implementar atributos Hreflang:
- En encabezados HTTP
- A través de etiquetas en la sección <head>
- A través de etiquetas en sitemap.xml
El método más fácil de implementar es a través de etiquetas en la sección <head>.
Existen las reglas que deben cumplir los atributos hreflang implementados a través de etiquetas en la sección <head>:
-
- El atributo debe tener el siguiente formato: <link rel=»alternate» hreflang=»lang_code_country_code» href=»url-of-page» />
- Los códigos de idioma y país deben ser válidos. Para elegir el código válido para cada mutación lingüística, consulte esta página.
- Cada versión de idioma debe enumerarse a sí misma, así como a todas las demás versiones de idioma en sus atributos hreflang. Significa que cada página debe tener el mismo número de atributos hreflang
- Los enlaces en atributos hreflang deben ser absolutos e indexables.
Un ejemplo de un código:
<link rel=»alternate» href=»https://example.com/en-us/page» hreflang=»en-us» />
<link rel=»alternate» href=»https://example.com/en-gb/page» hreflang=»en-gb» />
<link rel=»alternate» href=»https://example.com/en-us/page» hreflang=»x-default» />
Verifique los títulos, h1, h2s y descripciones en busca de duplicados
Aunque los títulos, las descripciones y los encabezados H1-H6 están relacionados con el SEO en la página, su análisis dentro de una auditoría técnica puede ser útil para detectar duplicados.
Para analizarlos, puede utilizar cualquier rastreador que recopile estas etiquetas.
Cuando se encuentren títulos, etiquetas H1-H6 y descripciones duplicadas, analice los datos de la página e identifique la causa de la duplicación. Esto puede deberse a la disponibilidad del sitio a través de HTTP y HTTPS, la duplicación de las etiquetas de categoría principal en las páginas de filtro o simplemente un error humano en el que estas etiquetas se completaron incorrectamente.
Optimizar los atributos alt de las imágenes
Los atributos Alt son un atributo HTML que se utiliza dentro de la etiqueta <img> de la siguiente manera: <img src=»image.jpg» alt=» Descripción de la imagen»>. Su objetivo principal es proporcionar una descripción textual del contenido de la imagen. Este texto se muestra si la imagen no se carga y los lectores de pantalla la leen en voz alta para ayudar a los usuarios con discapacidad visual. El texto alternativo descriptivo adecuado puede ayudar a que sus imágenes se clasifiquen en la búsqueda de imágenes y mejorar la relevancia general de la página.
Si tiene un sitio web con mucho contenido visual, la optimización de los atributos alt es un paso más importante que para los sitios web clásicos que se basan en contenido de texto.
Muchos rastreadores como Screaming Frog, Ahrefs, SemRush, etc. analizan los atributos alt, y allí puede obtener los datos sobre los atributos alt faltantes o vacíos.
Puede leer más sobre la creación de atributos alt descriptivos en documentos oficiales de Google.
Velocidad del sitio web, móvil y facilidad de uso
Usar protocolo HTTPs
El uso del protocolo seguro HTTPS es esencial para garantizar la seguridad de la transmisión de datos entre el usuario y el servidor. No solo aumenta la confianza del usuario, sino que también tiene un impacto positivo en el SEO. Para verificar HTTPS, simplemente mire la barra de direcciones del navegador: debería aparecer un ícono de candado.
Para un análisis detallado, puede utilizar el servicio SSL Labs, que proporcionará un informe completo sobre el estado del certificado SSL e identificará cualquier problema potencial.
También es importante asegurarse de que no haya contenido mixto: recursos HTTP en páginas HTTPS. Para este análisis, puede utilizar el informe HTTPS de Google Search Console, que mostrará las URL con HTTP y HTTPS.

Source: Search Console
Mejore las Core Web Vitals
Core Web Vitals es un conjunto de métricas propuestas por Google para evaluar la calidad de la experiencia del usuario en un sitio web. Estas métricas se centran en la velocidad de carga, la interactividad y la estabilidad visual del contenido de la página. Incluyen tres indicadores clave:
| Descripción de la métrica | Valor óptimo | |
|---|---|---|
| Pintura con contenido más grande (LCP) | Mide el tiempo de carga del elemento visible más grande de la página (por ejemplo, imagen o texto). | Menos de 2,5 segundos |
| Retardo de la primera entrada (FID) | Mide el tiempo que tarda la página en responder a la primera interacción del usuario (por ejemplo, hacer clic en un botón o enlace). | Menos de 100 milisegundos |
| Cambio de layout acumulativo (CLS) | Evalúa la estabilidad visual de la página, es decir, cuánto se mueven los elementos durante la carga de la página. | Menos de 0,1 |
Los datos recopilados de usuarios reales se pueden ver en el informe de Search Console «Core web vitals» (datos agregados) o en PageSpeed Insights (para pruebas individuales). Mientras trabaja en Core Web Vitals, tenga en cuenta que debe definir los problemas que tienen una gran influencia en las métricas de CWV. Por ejemplo, al optimizar LCP, debe definir cuál de los 4 aspectos (TTFB, Retraso de carga, Tiempo de carga o Retraso de renderizado) contribuye más a la alta puntuación de LCP.
En el siguiente ejemplo, es visible que no necesitamos centrarnos en la optimización de TTFB o Load Time. En cambio, podemos poner todas nuestras energías en mejorar el retraso de carga y luego el retraso de renderizado.

Source: pagespeed.web.dev
Asegúrese de que su sitio web sea compatible con dispositivos móviles
La compatibilidad con dispositivos móviles se ha convertido en un factor crucial desde 2018, cuando Google cambió a un enfoque de indexación móvil primero . Esto significa que Google ahora usa principalmente la versión móvil de un sitio web para clasificar e indexar, en lugar de la versión de escritorio.
En Google Search Console, puedes probar tus páginas haciendo clic en «Probar URL en vivo» en la herramienta de inspección de URL y ver cómo la ve Googlebot-Mobile.
Comprimir imágenes
La optimización de imágenes orientada a comprimirlas sin perder calidad ayuda a acelerar la carga del sitio web, especialmente si hay mucho contenido gráfico en las páginas.
Se pueden utilizar herramientas en línea como TinyPNG o Squoosh para comprimir imágenes. También vale la pena verificar si se están utilizando formatos de imagen modernos, como WebP, ya que pueden reducir significativamente el tamaño del archivo.
Usar CDN para sitios web internacionales
El uso de una CDN tiene sentido si su sitio web sirve a una amplia gama de regiones geográficamente distantes.
Una CDN (Content Delivery Network) distribuye el contenido del sitio a través de servidores ubicados más cerca de los usuarios, reduciendo la latencia durante la carga. Puede verificar el uso de CDN examinando los encabezados de solicitud HTTP en las herramientas de desarrollo del navegador (pestaña Red), donde pueden aparecer referencias al proveedor de CDN, como Cloudflare o Akamai. También hay herramientas en línea para probar CDN. La configuración de CDN generalmente se realiza a través del panel de alojamiento o CMS.
Usar el almacenamiento en caché
El almacenamiento en caché permite que los navegadores y los servidores proxy almacenen copias de los recursos, lo que reduce la carga del servidor y acelera la carga en visitas posteriores. Puede verificar la corrección del almacenamiento en caché en las herramientas de desarrollo del navegador: en la sección Red, consulte los encabezados Cache-Control, Expires y ETag. Google PageSpeed Insights también proporciona recomendaciones para el almacenamiento en caché. Es importante que los recursos estáticos (imágenes, scripts, estilos) tengan una configuración de almacenamiento en caché adecuada, y que el servidor tenga configuradas las reglas correspondientes (por ejemplo, en la configuración de .htaccess o nginx). Para verificar el almacenamiento en caché, puede utilizar servicios en línea como GiftOfSpeed.
Conclusión
Una auditoría técnica de un sitio web no es un procedimiento único, sino un proceso continuo que requiere una atención regular a los factores técnicos que pueden afectar su rendimiento y visibilidad. Como cada sitio web es único, el enfoque específico y la frecuencia de las comprobaciones variarán. Esta lista de verificación para una auditoría técnica de SEO lo ayudará a asegurarse de que no ha olvidado nada importante.