Checklist de SEO técnico: qué revisar en tu sitio y cómo comprobarlo

El SEO técnico es lo que decide si Google puede encontrar, leer y mostrar tus páginas. Si esa base falla, el mejor contenido del mundo no aparece. La buena noticia es que casi todo se puede comprobar con herramientas gratuitas y criterios objetivos: una página está indexada o no lo está, una redirección es permanente o no lo es.

Esta checklist agrupa las revisiones por área. Para cada punto tienes qué mirar, cómo comprobarlo y cuándo es un problema. Úsala antes de un rediseño, tras una migración o cuando el tráfico orgánico cae sin explicación.

Herramientas que necesitarás (todas gratuitas o con versión gratuita): Google Search Console, el navegador (ver código fuente y herramientas de desarrollo), curl en la terminal, PageSpeed Insights y, para sitios grandes, un rastreador como Screaming Frog (la versión gratuita revisa hasta 500 URLs).

Nuestro diagnóstico gratuito automatiza varios de estos puntos sobre la página que indiques. Al final de esta guía tienes cuáles.

1. Rastreo: que Google pueda entrar

1.1 robots.txt existe y no bloquea lo importante. Abre tu-dominio.com/robots.txt. Debe responder con código 200 y no contener Disallow: / (que bloquea todo el sitio) salvo que sea un entorno de pruebas. Comprueba que no bloquea las carpetas de CSS o JavaScript que la página necesita para mostrarse.

1.2 robots.txt no se usa para «quitar» páginas del índice. Bloquear una URL en robots.txt impide que Google la rastree, pero no garantiza que salga del índice: puede seguir apareciendo sin descripción si otras páginas la enlazan. Para excluir una página del índice usa noindex, y deja que Google pueda rastrearla para que vea esa etiqueta.

1.3 Hay un sitemap XML válido y declarado. Debe listar solo URLs canónicas que responden 200, con el mismo dominio y protocolo que el sitio. Cada archivo admite hasta 50 000 URLs o 50 MB sin comprimir; si pasas de eso, usa un índice de sitemaps. Decláralo en robots.txt (Sitemap: https://tu-dominio.com/sitemap.xml) y envíalo en Search Console.

1.4 Las páginas importantes están a pocos clics de la home. En un rastreo, mira la «profundidad»: si páginas de servicio o de categoría están a 5 o más clics, enlázalas desde el menú, desde la home o desde artículos relacionados.

1.5 No hay páginas huérfanas. Una URL en el sitemap que ninguna otra página enlaza es difícil de rastrear y de posicionar. Compara la lista del sitemap con la de un rastreo del sitio.

2. Indexación: que Google decida guardarlas

2.1 Las páginas que quieres posicionar están indexadas. En Search Console, «Inspección de URL» te dice si una URL está en el índice. El informe «Páginas» muestra el conjunto y el motivo de cada exclusión.

2.2 Ninguna página importante tiene noindex. Revisa la etiqueta <meta name="robots" content="noindex"> y la cabecera HTTP X-Robots-Tag. Es un error clásico de rediseños: el noindex del entorno de pruebas llega a producción.

2.3 Cada página declara una URL canónica coherente. La etiqueta <link rel="canonical"> debe ser una URL absoluta, con HTTPS, del mismo dominio, y debe apuntar a sí misma o a la versión preferida. Problemas típicos: canonical a otro dominio, a la versión http://, a una URL que redirige, o varias canonicals distintas en la misma página.

2.4 Una sola versión del sitio responde. Las cuatro variantes (http:// y https://, con y sin www) deben terminar en una con redirección 301. Compruébalo con curl -I en cada una.

2.5 Las URLs con parámetros y filtros no generan miles de duplicados. En tiendas y buscadores internos, decide qué combinaciones se indexan y canonicaliza o excluye el resto.

2.6 El contenido duplicado está controlado. Páginas casi idénticas (por ciudad, por variante de producto) compiten entre sí. Consolídalas o diferéncialas con contenido propio.

3. Códigos de respuesta y redirecciones

3.1 Conoce qué significa cada código.

Código	Significado	Uso correcto
200	La página existe	Páginas normales
301 / 308	Redirección permanente	Cambio definitivo de URL: transfiere señales a la nueva
302 / 307	Redirección temporal	Solo si el cambio es realmente temporal
304	No modificado (caché)	Normal en la revalidación; qué significa
404	No encontrada	URLs que nunca existieron o se eliminaron sin reemplazo
410	Eliminada de forma definitiva	Contenido retirado a propósito
5xx	Error del servidor	Siempre un problema: revisa el hosting

3.2 Las redirecciones son de un solo salto. A → B → C debe convertirse en A → C. Las cadenas largas desperdician rastreo y ralentizan. Comprueba con curl -IL https://tu-dominio.com/pagina-antigua/.

3.3 No hay «soft 404». Una URL inexistente debe devolver 404 real. Pruébalo: abre una ruta inventada y mira el código con las herramientas de desarrollo. Si devuelve 200 con un mensaje de «no encontrado», Google la trata como página de poco valor.

3.4 La página 404 ayuda. Que enlace a las secciones principales y a un buscador, y que conserve la cabecera del sitio.

3.5 En una migración, cada URL antigua tiene su redirección 301 a su equivalente más cercano. Nunca redirijas todo a la home. Mantén una tabla versionada de redirecciones.

4. HTTPS y seguridad

4.1 Todo el sitio se sirve por HTTPS con un certificado SSL válido y sin advertencias del navegador.

4.2 No hay contenido mixto. Ninguna imagen, script u hoja de estilo cargada por http:// dentro de una página https://. Las herramientas de desarrollo del navegador lo avisan en la consola.

4.3 http:// redirige a https:// con 301.

4.4 Cabeceras de seguridad básicas. Strict-Transport-Security (HSTS) con una vigencia larga una vez que estés seguro de que todo funciona por HTTPS, y X-Content-Type-Options: nosniff. No son un factor de posicionamiento directo, pero forman parte de un sitio bien configurado.

5. Estructura de URLs y contenido on-page

5.1 URLs cortas, legibles y estables. Minúsculas, palabras separadas por guiones, sin parámetros innecesarios. Cambiarlas tiene costo (redirecciones): hazlo solo con motivo.

5.2 Cada página tiene un título (<title>) único y descriptivo. Como referencia práctica, entre 30 y 60 caracteres para que no se corte en los resultados. No hay una longitud oficial: lo que importa es que sea claro y distinto en cada página.

5.3 Cada página tiene una meta description propia. No es un factor de ranking, pero influye en que hagan clic. Alrededor de 150-160 caracteres para que no se trunque.

5.4 Un H1 por página y una jerarquía lógica (H1 → H2 → H3, sin saltos). Sirve a la accesibilidad y a que Google entienda la estructura.

5.5 Todas las imágenes informativas tienen texto alternativo descriptivo. Las decorativas llevan alt="".

5.6 Enlazado interno con texto descriptivo. Evita «haz clic aquí»; enlaza con la frase que describe el destino. Revisa que no haya enlaces sin texto (solo con iconos, sin aria-label).

6. Rendimiento y Core Web Vitals

Google publica los umbrales de las tres métricas, medidas en el percentil 75 de las visitas reales:

Métrica	Qué mide	«Bueno»	«Deficiente»
LCP (Largest Contentful Paint)	Cuánto tarda en verse el contenido principal	≤ 2,5 s	> 4 s
INP (Interaction to Next Paint)	Qué tan rápido responde a clics y toques	≤ 200 ms	> 500 ms
CLS (Cumulative Layout Shift)	Cuánto «salta» el diseño al cargar	≤ 0,1	> 0,25

6.1 Mide con datos reales y de laboratorio. En PageSpeed Insights, distingue los «datos de usuarios reales» (los que cuentan) de la prueba de laboratorio (para diagnosticar). En Search Console, el informe de Core Web Vitals agrupa las URLs por problema.

6.2 Corrige por causa, no por puntuación. LCP lento suele deberse a imágenes pesadas, fuentes o servidor lento; CLS a imágenes sin dimensiones o anuncios que empujan el contenido; INP a JavaScript pesado.

6.3 Imágenes en formato moderno y con dimensiones definidas (width y height), con carga diferida (loading="lazy") para las que están fuera de la pantalla inicial, pero no para la imagen principal.

6.4 Compresión y caché. El HTML debe servirse comprimido (gzip o Brotli) y los archivos estáticos con caché de larga duración.

6.5 Tiempo de respuesta del servidor razonable. Si la primera respuesta tarda más de un par de segundos, el problema está en el hosting o en la aplicación, no en el front.

7. Móvil

7.1 Etiqueta viewport correcta: <meta name="viewport" content="width=device-width, initial-scale=1">. No bloquees el zoom.

7.2 Mismo contenido en móvil y escritorio. Google indexa principalmente la versión móvil; lo que solo exista en escritorio puede no contar.

7.3 Elementos táctiles cómodos. Botones y enlaces con espacio suficiente para no pulsar el vecino.

8. JavaScript y renderizado

8.1 El contenido y los enlaces importantes están en el HTML inicial o se renderizan de forma fiable. Compara «Ver código fuente» con la inspección del DOM. Si el texto solo aparece después de ejecutar JavaScript, no todos los rastreadores lo verán.

8.2 Los enlaces son <a href> reales. Un onclick sobre un div no es un enlace que un rastreador pueda seguir.

8.3 Las rutas del sitio devuelven códigos correctos. En aplicaciones de una sola página, una ruta inexistente debe devolver 404 del servidor, no un 200 con un mensaje.

9. Datos estructurados (schema)

9.1 Marcado de la organización o persona (Organization, LocalBusiness o Person) con nombre, URL y perfiles oficiales (sameAs).

9.2 Marcado acorde con el tipo de página: Article en artículos (con autor y fecha), BreadcrumbList en la navegación, Product en fichas de producto, FAQPage solo si las preguntas son visibles en la página.

9.3 El JSON-LD es válido y coincide con lo que se ve. Valídalo con la Prueba de resultados enriquecidos de Google y con el validador de schema.org. No marques información que la página no muestra.

10. Sitios internacionales

10.1 hreflang recíproco. Si la página A declara a B como alternativa, B debe declarar a A. Incluye la propia URL y, si aplica, x-default.

10.2 Códigos de idioma y país válidos (es-EC, es-ES, en-US). Un código inventado se ignora.

10.3 Cada versión con su canonical a sí misma, no a la versión principal.

11. Antes de lanzar una migración o rediseño

• Inventario de URLs, con tráfico, palabras clave y enlaces entrantes.
• Mapa de redirecciones 301 uno a uno, probado en un entorno de pruebas.
• Entorno de pruebas con noindex y verificación de que se quita al publicar.
• Títulos, encabezados y contenido útil conservados en la primera fase.
• Sitemap y robots.txt nuevos, enviados a Search Console.
• Rastreo comparativo antes y después.
• Vigilancia de Search Console las semanas siguientes: cobertura, errores 404, rastreo.

Cómo priorizar lo que encuentres

Una revisión completa casi siempre arroja más problemas de los que puedes arreglar de una vez. Ordénalos así:

Prioridad	Tipo de problema	Ejemplos	Qué hacer
1. Bloqueantes	Impiden que Google acceda o indexe	noindex en páginas importantes, Disallow: /, sitio caído, errores 5xx, HTTPS roto	Corregir de inmediato
2. Graves	Diluyen señales o pierden rastreo	Canonicals erróneas, cadenas de redirecciones, versiones del sitio duplicadas, soft 404, contenido mixto	Corregir en las próximas semanas
3. Mejoras	Aportan valor sin ser urgentes	Títulos y descripciones, textos alternativos, enlazado interno, datos estructurados	Planificar por lotes
4. Refinamientos	Ajustes de bajo impacto	Cabeceras de seguridad adicionales, microoptimizaciones de velocidad	Hacer cuando haya margen

Dentro de cada nivel, prioriza las páginas que generan consultas o ventas: un error en una página de servicio pesa más que el mismo error en una entrada antigua del blog.

Plantilla para registrar la revisión

Lleva un registro sencillo, en una hoja de cálculo, para no repetir trabajo y poder comparar entre revisiones:

Punto de la checklist	URL o sección	Estado	Evidencia	Responsable	Fecha
2.2 noindex	/servicios/	Correcto	Captura de la inspección de URL	(nombre)	(fecha)
3.2 Cadena de redirecciones	/antigua/	Corregir	curl -IL muestra 3 saltos	(nombre)	(fecha)

La columna de evidencia es la más útil: obliga a comprobar en lugar de suponer, y sirve si más adelante hay que explicar por qué se tomó una decisión.

Con qué frecuencia repetirla

• Antes y después de cada cambio grande (rediseño, cambio de plataforma o de dominio, migración de hosting).
• Cada trimestre para sitios que publican con regularidad.
• Al detectar una caída de tráfico sin causa clara.
• Cada semana, solo lo esencial: cobertura en Search Console, errores del servidor y el estado de las páginas clave.

Preguntas frecuentes

¿Puedo hacer esta revisión sin conocimientos técnicos? Buena parte, sí: la mayoría de las comprobaciones se hacen mirando Search Console, el código fuente o los resultados de PageSpeed Insights. Para corregir, quizá necesites a quien administra tu sitio.

¿Qué pasa si mi sitio es pequeño? Las mismas comprobaciones aplican, pero muchas serán rápidas: un sitio de diez páginas no tiene problemas de profundidad de rastreo, y sí puede tener un noindex olvidado.

¿El SEO técnico es lo primero que debo arreglar? Si hay un bloqueante, sí. Si tu sitio ya se indexa bien, el contenido y la autoridad suelen mover más el resultado.

¿Con qué frecuencia cambian estos umbrales de rendimiento? Google los ha actualizado en el pasado (por ejemplo, INP reemplazó a FID como métrica de interactividad). Confirma los valores vigentes en la documentación oficial antes de fijar objetivos.

¿Sirve una herramienta automática en lugar de esta checklist? Sirve como primera lectura y para no olvidar puntos. No reemplaza el criterio: una herramienta te dice que algo falla, no siempre por qué ni qué conviene hacer primero.

Qué revisa nuestro diagnóstico automático

El diagnóstico SEO gratuito comprueba sobre la página que indiques, entre otros: HTTPS y redirecciones, robots.txt, sitemap, canonical, noindex, variantes con y sin www, error 404 real, compresión y caché, cabeceras de seguridad, título, meta description, H1 y encabezados, texto alternativo, Open Graph, enlaces internos, datos estructurados y Core Web Vitals vía PageSpeed Insights. Es una primera lectura de una página y de los archivos base, no una auditoría de todas las URLs: para sitios grandes, rastrea el sitio completo.

Si prefieres que lo revise alguien y que se traduzca en un plan priorizado, conoce nuestro servicio de posicionamiento SEO.