Dev.to WebDev 🛠 Dev 👁 0 📖 6 min read

Auditoría SEO técnica paso a paso: checklist para devs con comandos (2026)

Si eres dev, tarde o temprano alguien de marketing te va a decir "la web no posiciona, revisa el SEO". Y muchas veces el problema no es de contenido: es un noindex que quedó de staging, un canonical mal armado por el fra

Si eres dev, tarde o temprano alguien de marketing te va a decir "la web no posiciona, revisa el SEO". Y muchas veces el problema no es de contenido: es un noindex que quedó de staging, un canonical mal armado por el framework o una cadena de redirecciones que nadie vio.

Esta es una auditoría SEO pensada para quien prefiere la terminal antes que un dashboard. La idea es encontrar en pocas horas los fallos técnicos que bloquean a Google, con comandos que puedes copiar, y dejar al final una lista priorizada para el equipo.

1. Lo que necesitas

  • Acceso a Google Search Console de la propiedad (idealmente de dominio, no de prefijo).
  • curl, grep y algo de jq o Python.
  • La lista de URLs que importan al negocio. Pídesela a marketing: no todas las páginas valen lo mismo.

2. Respuesta del servidor y redirecciones

Primero confirma que cada versión del dominio termina en un solo destino con un único 301:

for u in http://ejemplo.pe http://www.ejemplo.pe https://www.ejemplo.pe https://ejemplo.pe; do
  curl -s -o /dev/null -w "$u -> %{http_code} %{redirect_url}\n" "$u"
done

Qué buscar:

  • Cadenas (301 a 301 a 200). Cada salto extra es rastreo desperdiciado.
  • 302 donde debería ir 301, típico de configuraciones de hosting por defecto.
  • Slash final inconsistente: /servicios y /servicios/ respondiendo 200 los dos es contenido duplicado.

3. robots.txt y meta robots

curl -s https://ejemplo.pe/robots.txt
curl -s https://ejemplo.pe/pagina-clave/ | grep -iE '<meta[^>]+robots'
curl -sI https://ejemplo.pe/pagina-clave/ | grep -i x-robots-tag

Errores frecuentes:

  • Disallow: / heredado del entorno de staging.
  • Bloquear /wp-content/ o carpetas de JS y CSS, lo que impide a Google renderizar la página.
  • Un header X-Robots-Tag: noindex puesto por el CDN o el servidor, invisible en el HTML.

Recuerda: robots.txt evita el rastreo, no la indexación. Para sacar algo del índice se usa noindex, y para que Google lo lea la URL no debe estar bloqueada en robots.

4. Canonicals

curl -s https://ejemplo.pe/pagina-clave/ | grep -io '<link[^>]*canonical[^>]*>'

Cada URL importante debe tener un canonical absoluto que apunte a sí misma. Revisa especialmente:

  • Frameworks SPA que inyectan el canonical por JavaScript y lo dejan igual en todas las rutas.
  • Páginas con parámetros (?utm_, ?orderby=) que no canonicalizan a la versión limpia.
  • Canonical apuntando a http cuando el sitio es https.

5. Sitemap

curl -s https://ejemplo.pe/sitemap.xml | grep -o '<loc>[^<]*' | sed 's/<loc>//' > urls.txt
while read u; do
  echo "$(curl -s -o /dev/null -w '%{http_code}' "$u") $u"
done < urls.txt | grep -v '^200'

Si ese último comando devuelve algo, tu sitemap tiene URLs rotas o redirigidas. El sitemap solo debe listar URLs 200, indexables y canónicas. Luego compara contra el informe "Páginas" de Search Console: las URLs del sitemap marcadas como "Rastreada, actualmente sin indexar" son tu primera cola de trabajo.

6. Renderizado y JavaScript

Si el sitio es React, Vue o similar sin SSR, compara el HTML crudo con lo que ve el usuario:

curl -s https://ejemplo.pe/pagina-clave/ | grep -c '<h1'

Si devuelve 0 y en el navegador ves un H1, el contenido depende del render en cliente. Usa la "Inspección de URLs" de Search Console y mira el HTML renderizado. Si falta contenido o enlaces internos, considera SSR o pre-render para las rutas que posicionan.

7. On page mínimo verificable

Por cada URL clave revisa, con un script o a mano:

  • <title> único y con la keyword principal al inicio.
  • Un solo <h1>.
  • meta description presente.
  • Imágenes con alt y en WebP o AVIF.
  • Enlaces internos con <a href> reales, no onclick.

Un atajo para revisar esto sin salir del navegador es la extensión SEO Panel, que muestra title, headings, canonical y robots de la página abierta.

8. Core Web Vitals

Usa datos de campo, no solo Lighthouse local. La API de PageSpeed Insights te da ambos:

curl -s "https://www.googleapis.com/pagespeedonline/v5/runPagespeed?url=https://ejemplo.pe/&strategy=mobile" \
  | jq '.loadingExperience.metrics | keys'

Las referencias de Google para un resultado "bueno" son LCP menor a 2.5 s, INP menor a 200 ms y CLS menor a 0.1. Culpables habituales: imagen hero sin fetchpriority="high", fuentes sin font-display: swap, scripts de terceros (chat, pixeles) cargados en el <head> y banners que empujan el layout.

9. Datos estructurados

curl -s https://ejemplo.pe/ | grep -o '<script type="application/ld+json">.*</script>' | head -c 2000

Valida con la Prueba de resultados enriquecidos de Google. Para un negocio local lo mínimo es Organization o LocalBusiness con nombre, dirección y teléfono iguales a los del Perfil de Empresa de Google.

10. Hreflang (solo si hay varios idiomas o países)

Cada versión debe enlazar a todas las demás y a sí misma, con códigos válidos (es-PE, es-MX, en-US). Un hreflang sin retorno se ignora.

Errores que más se repiten en sitios hechos a medida

En auditorías de sitios de negocios en Perú hay patrones que aparecen una y otra vez, sobre todo en webs entregadas por agencias de desarrollo:

  • El entorno de staging indexado. staging.ejemplo.pe o dev.ejemplo.pe abiertos y con contenido duplicado del sitio real. Protégelos con autenticación básica, no solo con noindex.
  • Migraciones sin mapa de redirecciones. Se cambia de WordPress a Next.js, las URLs cambian y nadie redirige las antiguas. El tráfico cae en semanas. Antes de migrar exporta todas las URLs con tráfico desde Search Console y mapea cada una a su destino.
  • Paginación y filtros infinitos. Ecommerce con ?color=, ?talla= y ?page= combinables genera miles de URLs casi idénticas. Decide qué combinaciones merecen indexarse y canonicaliza o bloquea el resto.
  • Formularios y WhatsApp sin medir. El sitio "no convierte", pero en realidad nadie configuró eventos. Sin medición, ninguna mejora de SEO se puede demostrar.

Checklist rápido para copiar en el ticket

  • [ ] Una sola versión del dominio, un solo 301
  • [ ] Sin cadenas de redirección
  • [ ] robots.txt sin bloqueos de producción
  • [ ] Sin noindex ni X-Robots-Tag no deseados
  • [ ] Canonical autorreferente y absoluto en URLs clave
  • [ ] Sitemap solo con URLs 200 e indexables
  • [ ] Contenido y enlaces presentes en el HTML renderizado
  • [ ] Title, H1 y description únicos
  • [ ] Core Web Vitals en verde con datos de campo
  • [ ] Datos estructurados válidos
  • [ ] Hreflang recíproco (si aplica)

Cómo entregar los hallazgos

Una auditoría sin prioridad no se implementa. Entrega una tabla con hallazgo, URL afectada, impacto, esfuerzo y responsable. Indexación y canonicals primero, rendimiento después. Y antes de tocar nada, guarda clics e impresiones de Search Console como línea base.

La parte técnica es solo un tercio. Canibalización de keywords, contenido delgado e intención de búsqueda requieren criterio de negocio. Si el sitio es grande o la caída de tráfico fue fuerte, conviene una revisión manual completa como la auditoría SEO que ofrece Sonni Vasquez en Lima, que cubre técnico, on page y off page con una hoja de ruta priorizada.

FAQ

¿Lighthouse basta para una auditoría SEO?
No. Lighthouse mide rendimiento en laboratorio y algunas buenas prácticas. No ve indexación, canibalización ni enlaces.

¿Bloquear una URL en robots.txt la saca de Google?
No necesariamente. Para desindexar usa noindex y deja la URL rastreable.

¿Cada cuánto repetir esto?
Después de cada deploy grande, migración o cambio de framework. Automatiza los pasos 2 a 5 en CI y te ahorras sorpresas.

📰 Read the original article on Dev.to WebDev

Originally published by Dev.to WebDev. Aggregated on AIWithGhost for educational purposes — full credit and traffic to the original publisher.