Checklist de SEO técnico para desarrolladores: qué revisar antes de cada deploy

Un checklist de SEO técnico para desarrolladores es la lista de verificaciones que el equipo corre antes y después de cada deploy para asegurar que Google puede rastrear, renderizar e indexar las páginas que importan. No reemplaza una estrategia, pero evita el error más caro: un release que funciona perfecto para los usuarios y deja el sitio invisible para los buscadores.

Esta lista está pensada para quien escribe el código. Cada punto dice qué revisar, cómo detectarlo y qué suele fallar en la práctica.

Por qué el SEO técnico se rompe en los deploys

Los problemas técnicos rara vez aparecen por una decisión de marketing. Aparecen cuando una variable de entorno de staging llega a producción con un noindex, cuando se migra el router del framework y los enlaces pasan a ser botones, o cuando un cambio de plantilla duplica la canonical. Lo vimos en el rescate SEO tras una migración fallida: el mapa de redirecciones estaba incompleto y había canonicals mal implementadas. Al corregirlo, el tráfico orgánico creció un 500 % en 90 días, pero buena parte de la caída se habría evitado validando esos puntos antes del lanzamiento.

La solución es tratar el SEO como cualquier otro requisito no funcional: con criterios de aceptación, pruebas automatizadas y un responsable.

Checklist de rastreo e indexación

robots.txt y meta robots

• Confirma que el robots.txt de producción no tenga un Disallow: / heredado de staging.
• Recuerda que robots.txt controla el rastreo, no la indexación. Una URL bloqueada puede seguir en el índice si otros sitios la enlazan.
• Para excluir una página del índice usa <meta name="robots" content="noindex"> o la cabecera X-Robots-Tag, y deja la URL rastreable para que Google lea la instrucción.
• No bloquees CSS ni JavaScript necesarios para renderizar la página.

Códigos de estado HTTP

• Las páginas válidas responden 200. Las eliminadas, 404 o 410.
• Evita los “soft 404”: páginas de “producto no encontrado” que responden 200. En aplicaciones de una sola página (SPA) este error es frecuente porque el servidor siempre entrega el mismo HTML.
• Los errores 5xx sostenidos hacen que Google reduzca el ritmo de rastreo. Monitorea la respuesta del servidor, no solo la del CDN.

Tamaño y peso del HTML

Googlebot tiene límites sobre cuánto contenido de cada archivo procesa. Si tu HTML incluye estado serializado enorme o SVG en línea, revisa cómo afectan los límites de rastreo de Google a tu sitio y asegúrate de que el contenido principal esté al comienzo del documento.

Checklist de renderizado y JavaScript

Google renderiza JavaScript, pero lo hace en una fase posterior al rastreo y cualquier error de ejecución deja contenido fuera. Otros buscadores y muchos rastreadores de asistentes de IA ejecutan todavía menos JavaScript.

• Contenido principal en el HTML inicial. Con renderizado en servidor (SSR) o generación estática (SSG), el title, la meta description, la canonical, el H1 y el texto principal llegan sin depender del cliente.
• Enlaces rastreables. Google sigue elementos <a> con un atributo href que contiene una URL. Un <span onclick="router.push()"> o un href="javascript:void(0)" no se sigue.
• URL reales para cada estado. Evita fragmentos (#/producto) como ruta principal; usa la History API.
• Lazy loading con criterio. No difieras con JavaScript el contenido que quieres posicionar. Para imágenes, usa loading="lazy" nativo, salvo en la imagen principal de la vista inicial.
• Prueba lo que ve Google. La herramienta de inspección de URL de Search Console muestra el HTML renderizado y los recursos que no se pudieron cargar.

Checklist de canonicals, duplicados y parámetros

Situación	Qué revisar	Error típico
Página con variantes (color, orden, filtros)	Canonical a la versión principal	Canonical autorreferente en cada variante
Paginación	Cada página con su propia canonical	Todas las páginas apuntando a la 1
HTTP y HTTPS, con y sin www	Redirección permanente a una sola versión	Ambas versiones respondiendo 200
Barra final en la URL	Una sola convención en todo el sitio	Enlaces internos mezclando ambas
Parámetros UTM	Canonical sin parámetros	Parámetros que generan URL indexables

La canonical es una señal, no una orden. Si tus enlaces internos, el sitemap y las redirecciones apuntan a URL distintas de la canonical, Google puede elegir otra. La coherencia entre las tres cosas es lo que hace que funcione.

Checklist de redirecciones y migraciones

• Usa redirecciones permanentes del lado del servidor (301 o 308) para cambios definitivos.
• Evita cadenas: cada URL antigua debe llevar directo a su destino final.
• Mantén un mapa de redirecciones versionado en el repositorio, con pruebas que verifiquen el destino de las URL con más tráfico.
• Actualiza los enlaces internos para que apunten a la URL nueva; no dependas de la redirección.
• Después de una migración, revisa en Search Console el informe de indexación de páginas durante varias semanas.

Checklist de sitemaps, hreflang y datos estructurados

Sitemap XML

• Incluye solo URL canónicas, indexables y que respondan 200.
• Usa lastmod real: la fecha del último cambio significativo, no la del último build.
• Genera el sitemap en el build o en el servidor; los sitemaps escritos a mano quedan obsoletos.

hreflang para sitios multipaís

Si publicas para Chile, México y Colombia, cada versión debe declarar a las demás y a sí misma (por ejemplo es-CL, es-MX, es-CO), y las anotaciones deben ser recíprocas. Añade x-default para la versión genérica.

Datos estructurados

• Implementa JSON-LD con los tipos que aplican a tu contenido: Organization, Product, Article, BreadcrumbList, FAQPage según corresponda.
• El marcado debe describir contenido visible en la página. Marcar información que el usuario no ve incumple las directrices de Google.
• Valida con la prueba de resultados enriquecidos de Google antes de publicar.

Checklist de rendimiento y Core Web Vitals

Según web.dev, una página ofrece buena experiencia cuando, en el percentil 75 de visitas reales, cumple estos umbrales:

Métrica	Qué mide	Umbral “bueno”
LCP	Carga del elemento principal	≤ 2,5 s
INP	Respuesta a las interacciones	≤ 200 ms
CLS	Estabilidad visual	≤ 0,1

INP reemplazó a FID el 12 de marzo de 2024, según el anuncio oficial de web.dev. Para el detalle de cómo optimizar cada métrica, revisa nuestra guía de Core Web Vitals e INP. En el checklist de deploy basta con tres reglas:

1. Reserva espacio para imágenes, anuncios y banners (atributos width y height o aspect-ratio).
2. No agregues librerías de terceros sin medir su costo en el hilo principal.
3. Compara datos de campo (informe de Core Web Vitals en Search Console o CrUX) antes y después de cada cambio de plantilla.

Cómo automatizar el checklist

Un checklist que depende de la memoria de alguien falla en el release más apurado. Algunas formas de llevarlo al pipeline:

• Pruebas en CI que fallen si una página de producción devuelve noindex, si la canonical no coincide con la URL esperada o si el robots.txt cambió.
• Lighthouse CI con presupuestos de rendimiento por plantilla.
• Rastreo programado con Screaming Frog u otra herramienta similar para detectar 404, cadenas de redirección y canonicals rotas.
• Alertas de Search Console revisadas por alguien con nombre y apellido, no por un buzón compartido.

Si tu sitio acumula deuda técnica o se acerca una migración, una auditoría SEO antes del cambio cuesta mucho menos que recuperar el tráfico después.

Qué hacer con este checklist

Copia las secciones que aplican a tu stack, conviértelas en criterios de aceptación y revísalas en cada pull request que toque plantillas, rutas o infraestructura. Si necesitas ayuda para diagnosticar y priorizar, en Sprint LATAM trabajamos el SEO técnico junto a equipos de desarrollo: revisamos rastreo, renderizado, migraciones y rendimiento, y dejamos las verificaciones integradas en tu flujo de trabajo. Hablemos de tu SEO técnico.