Checklist de implementación de SEO técnico para desarrolladores web

Qué es esta checklist y cómo usarla

Esta checklist es un control de calidad (QA) orientado a desarrolladores para validar que un sitio es rastreable, indexable, consistente y eficiente antes y después de publicar. La idea es ejecutar los mismos puntos en dos momentos: pre-release (staging con acceso controlado) y post-release (producción), registrando evidencias comparables para detectar regresiones.

Flujo recomendado (paso a paso)

• 1) Preparar un listado de URLs: páginas clave (home, categorías, fichas, blog, buscador interno si existe, páginas legales, etc.) y una muestra representativa por tipo de plantilla.
• 2) Ejecutar validaciones por bloques (los de esta checklist) sobre ese listado.
• 3) Registrar evidencias (respuestas HTTP, capturas, exportaciones) y dejar trazabilidad por fecha/entorno/commit.
• 4) Corregir y revalidar hasta que el checklist quede en verde.
• 5) Repetir post-release y comparar resultados con staging.

Plantilla mínima de control (para cada URL)

Checklist accionable (pre y post publicación)

1) Rastreo e indexación

• robots.txt accesible: GET /robots.txt devuelve 200 (o 304) y el contenido corresponde al entorno (staging vs producción). Evidencia: respuesta completa (headers + body).
• Reglas coherentes: no bloquear recursos críticos necesarios para render (CSS/JS) si el sitio depende de ellos para generar HTML indexable. Evidencia: captura del archivo y nota de las rutas afectadas.
• Sitemap válido y actualizado: GET /sitemap.xml (o índice) devuelve 200, es XML válido, contiene URLs canónicas, y refleja cambios recientes. Evidencia: descarga del sitemap y conteo de URLs por tipo.
• Estados HTTP correctos: páginas indexables deben ser 200; redirecciones solo donde corresponda (301/308); no debe haber 404/5xx en URLs internas importantes. Evidencia: listado de URLs con su status.
• noindex donde corresponde: páginas de baja calidad o utilitarias (p. ej., resultados internos, filtros no deseados, pasos intermedios) deben llevar noindex de forma consistente. Evidencia: captura del <meta name="robots"> o header equivalente.

Cómo validar rápido (comandos)

# 1) robots.txt y sitemap con headers
curl -I https://example.com/robots.txt
curl -sS https://example.com/robots.txt | head
curl -I https://example.com/sitemap.xml

# 2) status HTTP y redirecciones (muestra)
curl -I https://example.com/una-url
curl -I -L https://example.com/url-que-redirige

# 3) extraer meta robots y canonical (HTML inicial)
curl -sS https://example.com/una-url | grep -iE "<meta name=\"robots\"|rel=\"canonical\""

2) Metadatos (consistencia por plantilla)

• Title presente y único por intención: evitar títulos vacíos, duplicados masivos o generados sin contexto. Evidencia: exportación de titles por tipo de página (tabla/CSV).
• Meta robots consistente: no mezclar index/noindex de forma accidental entre variantes (con parámetros, paginación, etc.). Evidencia: listado de URLs con su directiva.
• Canonical coherente: apunta a la versión preferida (normalizada) y no contradice noindex o redirecciones. Evidencia: captura del canonical y verificación de que responde 200.

3) URLs (normalización y redirecciones sin cadenas)

• Normalización: una sola versión por recurso (http→https, www/no-www, slash, mayúsculas, trailing slash, etc.). Evidencia: matriz de pruebas (variantes → destino final).
• Sin cadenas de redirecciones: evitar 2+ saltos (p. ej., http→https→www→/). Evidencia: curl -I -L mostrando la secuencia.
• Parámetros controlados: parámetros que no cambian el contenido principal no deben crear indexación accidental. Evidencia: ejemplos de URLs con parámetros y su canonical/noindex.

Ejemplo de evidencia de redirección (captura de terminal)

curl -I -L https://example.com
HTTP/2 301
location: https://www.example.com/
HTTP/2 200

4) Enlazado interno (rastreabilidad real)

• Sin páginas huérfanas: cada URL importante debe tener al menos un enlace interno desde una página rastreable. Evidencia: listado de URLs objetivo y desde qué URL se enlazan.
• Enlaces rastreables: evitar enlaces que dependan de eventos JS sin <a href>, o que estén bloqueados por atributos/fragmentos no rastreables. Evidencia: inspección del HTML inicial y captura del DOM (si aplica).
• Enlaces a 4xx/5xx: no debe haber enlaces internos rotos en navegación, listados, breadcrumbs, footer. Evidencia: reporte de enlaces rotos (URL origen → destino → status).

5) Schema.org (JSON-LD válido y consistente)

• JSON-LD válido: sin errores de sintaxis, tipos correctos por plantilla (p. ej., Organization, WebSite, BreadcrumbList, Product, Article). Evidencia: salida del validador y captura del bloque JSON-LD.
• Consistencia con el contenido visible: nombre, precio, disponibilidad, autor, fechas, etc. deben coincidir con lo que ve el usuario. Evidencia: comparación (captura de UI + JSON-LD).
• Sin duplicados conflictivos: evitar múltiples entidades que se contradicen (p. ej., dos Product distintos en la misma URL). Evidencia: listado de páginas con múltiples bloques y revisión.

6) Rendimiento (CWV y optimizaciones críticas aplicadas)

• Medición CWV: registrar métricas de laboratorio (Lighthouse) y, si existe, métricas de campo (RUM/CrUX). Evidencia: reportes exportados (HTML/JSON) y captura de valores.
• Optimización crítica verificada: recursos críticos (CSS/JS) controlados, caching correcto, compresión activa, y sin regresiones de peso/requests. Evidencia: captura de waterfall y tamaños de recursos.
• Comparativa pre vs post: misma URL, mismo dispositivo/perfil, mismo presupuesto de rendimiento. Evidencia: tabla con LCP/INP/CLS y peso total.

7) Imágenes (formatos, tamaño, lazy y CLS)

• Formatos y tamaños: servir formatos modernos cuando proceda y tamaños responsivos (evitar imágenes enormes reescaladas por CSS). Evidencia: captura de Network con tamaño transferido y dimensiones.
• Lazy loading correcto: lazy solo para imágenes fuera del viewport inicial; la imagen principal (hero/producto principal) no debe degradar LCP. Evidencia: captura del HTML (atributos) y medición LCP.
• CLS controlado: reservar espacio con width/height o CSS equivalente; evitar inserciones tardías que muevan layout. Evidencia: captura de Layout Shift en DevTools.

8) SPA/SSR (HTML inicial indexable y rutas/404 correctos)

• HTML inicial indexable: la respuesta inicial debe incluir contenido significativo (título, cuerpo, enlaces) sin depender exclusivamente de JS para mostrar lo esencial. Evidencia: curl del HTML y captura de “View Source”.
• Rutas y estados correctos: rutas inexistentes devuelven 404 real (no 200 con página de error), y las rutas válidas devuelven 200. Evidencia: pruebas con URLs inventadas y captura de headers.
• Hidratación sin romper metadatos: asegurar que title/robots/canonical no cambian a valores incorrectos tras la carga del cliente. Evidencia: captura antes/después (source vs DOM).

Cómo registrar evidencias (para control de calidad)

Qué guardar siempre

• Capturas de respuestas HTTP: headers completos (status, location, cache-control, content-type) y body relevante (robots.txt, sitemap, HTML). Ideal: logs de terminal.
• Listados de URLs: CSV/hoja con URLs por tipo, incluyendo variantes (con/sin slash, parámetros, etc.) y resultado de validación.
• Resultados de validación: exportaciones de Lighthouse, reportes de enlaces rotos, salida de validadores de Schema, y cualquier script interno de checks.
• Contexto de versión: entorno (staging/prod), fecha/hora, commit/tag, configuración (feature flags) y usuario/rol que ejecutó el QA.

Estructura sugerida de carpeta de evidencias

seo-qa/
  2026-02-02_pre-release_commit-abc123/
    urls.csv
    http/
      robots_headers.txt
      sitemap_headers.txt
      sample-url-1_headers.txt
    metadata/
      titles_export.csv
      canonicals_sample.txt
    links/
      broken-links.csv
    schema/
      validator_results.pdf
      jsonld_samples/
    performance/
      lighthouse_home.json
      lighthouse_categoria.json
      waterfall_home.png
  2026-02-05_post-release_commit-def456/
    ...

Formato de evidencia para respuestas HTTP (repetible)

# Guardar headers
curl -sS -D - -o /dev/null https://example.com/una-url > http/sample-url-1_headers.txt

# Guardar HTML (para inspección de meta/canonical/schema)
curl -sS https://example.com/una-url > http/sample-url-1.html

Checklist resumida para pasar a “Go/No-Go”