Checklist de auditoría SEO para desarrolladores: qué revisar y en qué orden

Una checklist de auditoría SEO no sustituye a un informe completo — pero sí evita el caos de «revisamos de todo un poco» y acabamos con veinte tickets sin prioridad. Si eres desarrollador, tech lead o PM con responsabilidad sobre el front, esta lista te da un recorrido ordenado: de lo que puede bloquear la indexación a lo que afina CTR y rich results.

El orden importa. Primero confirmas que Google puede indexar; después arreglas URLs, contenido técnico, velocidad y enlaces. Si quieres el contexto narrativo de cada bloque, complementa con nuestra auditoría SEO técnica paso a paso; aquí el foco es ejecutar y marcar casillas.

Índice

• Antes de empezar: URLs y herramientas
• Fase 1 — Indexación y rastreo
• Fase 2 — Arquitectura y URLs
• Fase 3 — On-page técnico
• Fase 4 — Rendimiento y Core Web Vitals
• Fase 5 — Enlaces internos y datos estructurados
• Cómo puntuar y priorizar hallazgos
• Errores que invalidan la auditoría
• Preguntas frecuentes

Antes de empezar: URLs y herramientas

No audites «el sitio entero» en abstracto. Elige una muestra representativa — suele bastar con 8–15 URLs:

• Home y 2–3 landings de servicio o producto.
• 1–2 entradas de blog con tráfico orgánico (Search Console).
• 1 plantilla de categoría o listado si aplica.
• 1 URL problemática que ya sospeches (404, lenta, duplicada).

Herramientas mínimas (gratuitas):

• Google Search Console — indexación, sitemap, CWV de campo.
• PageSpeed Insights — laboratorio + datos de campo por URL.
• Rich Results Test — schema y elegibilidad SERP.
• DevTools del navegador — red, consola, View Source.
• Rastreador desktop (Screaming Frog, Sitebulb, etc.) — opcional pero muy útil en sitios >50 URLs.

Si aún no tienes claro qué medir antes de abrir tickets, repasa SEO para desarrolladores: qué medir primero y la guía de DevTools para SEO.

Fase 1 — Indexación y rastreo

Si Google no indexa, nada de lo demás compite. Marca cada ítem; cualquier ❌ aquí es prioridad crítica.

• ☐ Propiedad correcta en Search Console (dominio o prefijo de URL coherente con producción).
• ☐ robots.txt no bloquea secciones indexables (blog, landings, fichas).
• ☐ URLs clave sin noindex accidental (meta robots o cabecera HTTP).
• ☐ Sitemap XML accesible, sin errores de procesamiento y alineado con URLs públicas.
• ☐ Inspección de URL en GSC: «URL está en Google» en home + 3 URLs de negocio.
• ☐ Canonical declarada = canonical seleccionada por Google (sin conflictos masivos).
• ☐ Sin picos de «Descubierta: no indexada» o «Duplicada» sin explicación en el informe de páginas.
• ☐ Respuestas HTTP correctas: 200 en contenido, 301 (no cadenas largas) en migraciones, 404 limpios donde toca.

Señal de alerta: plantillas de producto o blog con tráfico histórico que pasan a «Excluida» tras un deploy. Para el flujo completo de esta fase, ver el paso 1 de la auditoría técnica paso a paso.

Fase 2 — Arquitectura y URLs

• ☐ HTTPS en todo el sitio; una sola variante canónica de host (www vs no-www, barra final consistente).
• ☐ Redirecciones: máximo un salto 301 por URL migrada; sin bucles ni 302 permanentes por error.
• ☐ Profundidad de clic: páginas importantes a ≤3 clics desde home.
• ☐ Slugs legibles, estables y en el idioma correcto (sin mezclar /es/blog/english-slug/).
• ☐ Multidioma: hreflang recíproco y coherente si hay ES/EN u otros locales.
• ☐ Parámetros, filtros y ordenaciones: no generan miles de URLs indexables duplicadas.
• ☐ Subdominios de preview, staging o API no indexables ni enlazados desde producción.
• ☐ Sitemap y enlaces internos apuntan al dominio público, no al CMS oculto.

Fase 3 — On-page técnico

Recorre cada plantilla de la muestra (home, landing, artículo):

• ☐ Un solo <h1> claro por URL; jerarquía H2/H3 lógica.
• ☐ <title> único (~50–60 caracteres útiles) y meta description que invite al clic sin relleno.
• ☐ Canonical autoreferenciada salvo reglas de sindicación explícitas.
• ☐ Contenido principal visible en el HTML inicial (View Source muestra titular y cuerpo).
• ☐ Imágenes con alt descriptivo; formatos modernos (WebP/AVIF) cuando sea posible.
• ☐ Open Graph y Twitter Card básicos en plantillas compartibles.
• ☐ Paginación con enlaces crawlables o señales claras (no solo botones JS sin fallback).
• ☐ Sin títulos o descriptions duplicados masivos en la muestra del rastreo.

Fase 4 — Rendimiento y Core Web Vitals

Google usa señales de experiencia; LCP, INP y CLS resumen carga, respuesta e estabilidad. En la checklist:

• ☐ PageSpeed Insights en móvil para las 3–5 URLs con más impresiones o conversión.
• ☐ Informe Core Web Vitals en Search Console sin URLs «Poor» en plantillas de negocio.
• ☐ LCP: elemento principal identificado (hero, imagen producto, titular) y optimizado.
• ☐ INP: interacciones clave (menú, filtros, CTA) sin bloqueos largos del hilo principal.
• ☐ CLS: imágenes y embeds con dimensiones reservadas; banners que no empujan contenido.
• ☐ TTFB razonable en plantillas dinámicas (no confundir caché puntual con rendimiento real).
• ☐ Terceros auditados: analytics, chat, tags — cargan después del contenido crítico cuando sea posible.

Conceptos en profundidad: Core Web Vitals: qué son y qué medir. Para el workflow de velocidad paso a paso, usa la guía práctica de auditoría PageSpeed.

¿Quieres una primera foto rápida antes del informe largo? En la landing de SEO técnico tienes el simulador PageSpeed para probar una URL de tu muestra.

Fase 5 — Enlaces internos y datos estructurados

Enlaces internos

• ☐ Páginas nuevas enlazadas desde home, blog o landings relevantes.
• ☐ Sin enlaces rotos (404) en menús, footer o contenido legacy.
• ☐ Anclas descriptivas en enlaces contextuales (no solo «haz clic aquí»).
• ☐ Cluster temático: artículos relacionados se enlazan entre sí (auditoría, velocidad, arquitectura).

Datos estructurados

• ☐ Organization / WebSite en home sin errores críticos.
• ☐ Article o BlogPosting en entradas del blog.
• ☐ FAQPage solo donde las preguntas son visibles en la página.
• ☐ Product, LocalBusiness u otros tipos solo si aplican al negocio real.
• ☐ Rich Results Test sin errores que bloqueen el tipo de resultado esperado.

Guía de implementación en stacks modernos: Schema.org con Next.js.

Cómo puntuar y priorizar hallazgos

Cuando termines las cinco fases, no abras veinte tickets a la vez. Clasifica cada hallazgo:

Severidad	Ejemplos de la checklist	Acción
Crítica	noindex masivo, 5xx, migración sin 301, robots.txt bloqueando /blog/	Parar campañas; corregir en horas o días
Alta	Canonical incorrecta, sitemap roto, CWV «Poor» en URLs money	Sprint actual
Media	Titles duplicados, imágenes pesadas, enlaces rotos secundarios	Backlog 2–4 semanas
Baja	Schema opcional, micro-optimizaciones de alt	Cuando haya capacidad

Entrega un documento con: URL, evidencia (captura o export), severidad, responsable (dev, contenido, infra) y criterio de cierre. Una checklist de auditoría SEO que no termina en acciones concretas es solo una lista bonita en Notion.

Si tras la checklist valoras ayuda externa, consulta cuánto cuesta el SEO técnico para entender modelos de precio y qué debe incluir un presupuesto serio.

Errores que invalidan la auditoría

Medir solo la home en desktop con WiFi perfecto

Las plantillas que escalan (categoría, producto, artículo) suelen ser las que fallan en móvil. La home puede estar bien mientras el resto pierde tráfico.

Confundir puntaje Lighthouse con SEO

Un 100 en laboratorio no garantiza posición. CWV de campo y indexación importan tanto o más.

Ignorar el HTML inicial

Si View Source está vacío y el contenido solo aparece tras JavaScript, la checklist de on-page puede marcarse ✅ en DevTools pero ❌ para Google.

Arreglar schema antes que canonicals

Rich results no compensan URLs duplicadas o no indexadas. Respeta el orden de las fases.

No repetir la checklist tras cambios grandes

Rediseños, plugins nuevos o migraciones headless requieren pasar la lista otra vez — no asumas que «ya lo hicimos en enero».

Preguntas frecuentes

¿Cuánto tarda pasar esta checklist?

Con muestra de 10 URLs y herramientas abiertas: medio día a un día para una persona que conoce el proyecto. Sitios grandes necesitan rastreo automatizado y validación con desarrollo — de dos a cinco días.

¿Checklist vs auditoría SEO completa?

La checklist es el esqueleto operativo; la auditoría completa añade profundidad (enlaces externos, contenido, competencia). Empieza aquí si necesitas orden rápido; profundiza con la guía paso a paso si hay caída de tráfico.

¿Puedo automatizar parte de la lista?

Sí: rastreos programados, alertas de uptime, CI con Lighthouse, informes CWV. La interpretación de canonicals, hreflang y cambios de producto sigue necesitando criterio humano.

¿Con qué frecuencia repetirla?

Trimestral en sitios activos; mensual durante migraciones o lanzamientos grandes. Search Console alerta sobre picos, pero no sustituye una revisión programada.

¿Qué hago después de marcar todo?

Prioriza críticos y altos, asigna responsables y mide de nuevo en 4–6 semanas. Para velocidad, vuelve a PageSpeed Insights o al simulador de la landing SEO con las mismas URLs de la muestra.