¿Cada cuánto debería correr una auditoría SEO técnico?

Después de cualquier lanzamiento que toque plantillas, redirecciones o robots. Si no, una pasada real cada trimestre basta en la mayoría de los sitios. Lo semanal es para vigilar CWV y el informe de Páginas, no para volver a rastrear el universo.

¿Necesito Screaming Frog?

No para esta checklist. Lo necesitas cuando quieres el grafo interno completo, el descubrimiento con JS renderizado a escala, o un diff de rastreo contra rastreo. Tenemos una comparación si estás decidiendo.

¿Qué se corrige primero?

Lo que impida que las páginas que generan dinero se rastreen o se indexen. Todo lo demás es opcional hasta que eso esté hecho.

¿Core Web Vitals es un factor de ranking?

Google dice que la experiencia de página es parte de lo que premian los sistemas de fondo, y Core Web Vitals es como miden un pedazo de eso. No sustituyen a una página que no debería existir. Corrige primero la indexación.

¿Dónde entran los titles y el contenido?

Después de que la URL se pueda obtener y se pueda conservar. Un title brillante en una URL con `noindex` es un borrador.

Checklist de auditoría SEO técnico (el orden en que sí la corremos)

La mayoría de las auditorías técnicas empiezan en el lugar equivocado. Alguien abre un crawler, exporta 4,000 "problemas" y el primer ticket es una meta description que falta en una página de etiqueta que nadie visita.

Eso es un reporte. No es una auditoría.

Una auditoría SEO técnico responde una pregunta, en orden: si un rastreador puede encontrar la URL, obtenerla, renderizarla, conservarla, y si una persona puede usar la página una vez que rankea. Trabajas esa pila de arriba hacia abajo porque las capas de después son movimiento perdido si las de antes están rotas. No tiene sentido pulir el LCP de una URL que devuelve noindex.

Esta es la checklist que corremos. Search Console primero, después las revisiones concretas. No necesitas un spider de pago para terminarla. Sí necesitas honestidad sobre lo que una herramienta de navegador no puede ver.

Si estás a mitad de un cambio de plataforma, detente y usa la Checklist SEO de migración de sitio. Ese es otro trabajo.

Qué no estás haciendo

No estás puntuando la voz de marca. No estás armando un mapa de keywords. No estás reescribiendo el copy de producto.

Estás buscando lo que le impide a Google usar las páginas que ya tienes: recursos bloqueados, reglas de staging que se quedaron, canonicals que apuntan a un 301, sitemaps llenos de basura, plantillas que fallan Core Web Vitals, schema que describe un producto que el HTML no muestra.

Si un hallazgo no cambia el rastreo, el índice o la página renderizada, se va al fondo de la lista o se sale de ella.

Empieza en Search Console, no en un crawler

Abre la propiedad que de verdad te importa. Después mira, antes de generar un solo CSV:

Páginas. Cuántas están indexadas. Por qué el resto no. "Crawled — currently not indexed", "Excluded by noindex", "Blocked by robots.txt", "Alternate page with proper canonical": esas filas te dicen la forma del problema antes que cualquier herramienta de terceros.
Sitemaps. Enviadas frente a indexadas. Una brecha ancha es el número más útil de toda la auditoría. Suele significar que el sitemap miente, o que el sitio miente.
Core Web Vitals. Datos de campo, por plantilla si los puedes ver. Los puntajes de laboratorio pueden esperar.
Experiencia / HTTPS. Contenido mixto, usabilidad. No te quedes a vivir aquí, pero tampoco te lo saltes.

Anota las plantillas que generan dinero: home, categoría, producto, artículo, lo que pague las cuentas. El resto de esta checklist es esas plantillas primero, y después una muestra de la cola larga. Auditar cada URL facetada de un ecommerce es la forma de pasarte una semana describiendo un problema que ya entendiste el martes.

Una nota de primera pasada sobre una sola URL que genera dinero —indexabilidad, etiquetas on-page, schema, cabeceras— es para lo que sirve la Puntuación de preparación SEO. Úsala para ver si el paciente tiene pulso. Después haz el trabajo de abajo.

1. ¿Se puede rastrear?

Lee el robots.txt como una persona. Un 404 en ese archivo está bien. Un 500 no: Googlebot puede ponerse cauteloso con todo el host hasta que el archivo vuelva. Un Disallow: / que se quedó del staging sigue siendo el bug clásico de "lanzamos y desaparecimos".

Revisa que el CSS, el JS y las imágenes que Google necesita para renderizar la página no estén bloqueados. Después prueba las reglas que crees tener contra las URLs que te importan en el Tester de robots.txt de Google.

Después, el sitemap XML. Debería contener URLs canonical, indexables y con estado 200. Nada más. Ni páginas de gracias, ni 301, ni URLs de resultados de búsqueda, ni restos de staging. Pásalo por el Validador de sitemap XML para la sintaxis, y después por el Comprobador de errores del sitemap para las URLs de adentro. Si el archivo es XML válido y sigue lleno de redirecciones, el ticket es el plugin que lo escribió, no "el SEO".

Saca una lista de URLs importantes —sitemap más Search Console más la navegación— y pégalas en el Comprobador de estado de URL masivo. Quieres 200 en las que están vivas y una historia limpia para el resto. 1,000 URLs por pasada. Primero las páginas que generan dinero.

2. ¿Se puede indexar?

Poder rastrear no es indexar. Hay montones de sitios totalmente rastreables que igual dejan fuera sus mejores páginas.

Para la lista de URLs que generan dinero:

Nada de noindex accidental. Revisa la meta tag y el X-Robots-Tag. La cabecera es la que Ver código fuente no te va a mostrar. El Comprobador de noindex lee las dos.
Los canonicals apuntan adonde tú quieres. Autorreferenciados en páginas únicas. Nunca a una redirección, a un 404, a un noindex ni a una variante con parámetros que no quieres indexada. Comprobador de canonical en una muestra de cada plantilla. Los canonicals son una pista. Google ignora los tontos y elige el suyo, y por eso existe la fila de Search Console "Google chose different canonical".
Un host, un protocolo. http, https, www, sin www: tres de las cuatro deberían hacer 301 hacia la que declaraste. Pide cada variante y lee el estado. No des por hecho que el CDN está haciendo lo que decía el ticket.
Después haz la única pregunta que de verdad le importa al cliente: si esta URL está en Google o no, y si no está, si es por algo que hicimos nosotros. Eso es el Comprobador de indexación, más la inspección de URL en las mismas páginas. A veces no coinciden. Esa diferencia sirve.

Si el informe de Páginas es una pared de "Crawled — currently not indexed", no empieces a reescribir titles. Mira calidad, duplicación y si le estás pidiendo a Google que conserve 40,000 URLs filtradas casi idénticas. Eso es un problema de arquitectura, que es la sección siguiente, no un problema de meta tags.

3. ¿Una persona —y un bot— puede llegar desde la home?

La profundidad de rastreo es un proxy de "¿alguien se molestó en enlazar esto?". Las páginas enterradas a cinco clics, en un revoltijo de etiquetas, se rastrean al final y se olvidan primero. El Comprobador de profundidad de rastreo es la lectura rápida. Las plantillas importantes deberían estar cerca de la home. Si una categoría antes estaba en la navegación principal y ahora vive en un acordeón del footer, ese es el hallazgo.

Las huérfanas son la otra mitad. Están en el sitemap, no en el grafo interno. Un crawler de escritorio es mejor para una pasada completa de huérfanas. En una auditoría de trabajo igual puedes hacer un muestreo: si Search Console muestra impresiones en una URL a la que nada de la navegación ni del HTML enlaza, encontraste una.

Los enlaces internos rotos gastan rastreo y confianza. Pasa una plantilla que genera dinero por el Comprobador 404 y escáner de enlaces rotos. En un sitio WordPress, el Comprobador de enlaces rotos de WordPress recorre posts y páginas por la REST API, sin instalar un plugin que después se te olvida apagar.

Las cadenas de redirección van aquí, no en un apéndice de "estaría bien tenerlas". Los saltos de más son lentos y descuidados. Comprobador de cadenas de redirección en las URLs viejas de campaña, el par www/apex y cualquier cosa que marketing siga pegando en anuncios. Googlebot sigue hasta 10 saltos. No uses eso como presupuesto.

Hreflang, si tienes más de un locale: cada URL del grupo debería apuntar a las demás, incluida ella misma, y ninguno de esos destinos debería dar 404 ni redirigir. El Comprobador de hreflang es el pasa o no pasa. Un locale viejo mantiene vivo el host anterior después de una mudanza. Escribimos de eso en la checklist de migración porque sigue pasando.

4. ¿La página es la página que crees que es?

Duplicados. El mismo title y la misma description en 80 productos porque el tema reimprime el nombre de la categoría. URLs con parámetros que renderizan el mismo producto. HTTP y HTTPS, las dos en 200.

El Buscador de titles y metas duplicados es el instrumento romo. Después mira tú un par de URLs. Si el H1, el cuerpo y la intención son los mismos, elige un canonical y haz que la otra se vaya. Si son productos distintos con una plantilla floja, eso es un problema de title, no un sermón de contenido duplicado.

Paginación: rel=next/prev ya no es como Google hace esto, pero las URLs paginadas siguen teniendo que ser rastreables, no un noindex más un canonical de vuelta a la página 1 si de verdad quieres la página 7 en el índice. La mayoría de los ecommerce no debería querer la página 7 en el índice. Decide, y después revisa. Comprobador de paginación.

Los titles y las descriptions son técnicos solo cuando faltan, están duplicados o están tan recortados que dejan de funcionar como SERP. No conviertas esta sección en un taller de copy. Comprobador de title tags y Comprobador de meta descriptions en las plantillas que generan dinero, y ahí paras.

5. Core Web Vitals, por plantilla

Los Core Web Vitals actuales de Google —medidos en el percentil 75, móvil y desktop por separado— son:

LCP dentro de 2.5 segundos
INP en 200 milisegundos o menos
CLS en 0.1 o menos

Eso sale de web.dev y de Google Search Central. Los datos de campo en Search Console son la nota que importa. Una corrida de Lighthouse en el wifi de la oficina es una herramienta de depuración.

Revisa las plantillas que fallan en campo, no un post al azar que resulta estar en verde. El Comprobador de Core Web Vitals y el Comprobador de PageSpeed se apoyan en PageSpeed Insights, así que los números coinciden con lo que Google ya te mostró.

Corrige en este orden, porque suele ser el orden del impacto: la imagen de LCP (tamaño, compresión, preload, que no esté detrás de un script de carrusel), después el salto de layout (pon width y height, deja de inyectar banners arriba del title), después el INP (tags de terceros, trabajo del hilo principal). Imágenes: Comprobador de tamaño de imágenes, Comprobador de texto alt, Comprobador de lazy load. El texto alt es accesibilidad y búsqueda de imágenes. No va a salvar un LCP de 6 segundos.

Si una plantilla está en rojo en campo y en verde en laboratorio, créete el campo. Dispositivos distintos, redes distintas, gente real haciendo clic en cosas que Lighthouse nunca toca.

6. Datos estructurados que coincidan con la página visible

El schema no es una palanca de ranking que espolvoreas. Es una afirmación. Si el HTML no sostiene la afirmación, te ignoran o te llega un aviso de resultado enriquecido.

Revisa los tipos que de verdad usas —Article, Product, FAQ, Organization, BreadcrumbList— en una URL en vivo con el Validador de schema. Después, si tienes más que un puñado de plantillas, el Validador schema JSON-LD masivo. Busca campos obligatorios que faltan, tipos que dejó un plugin que desactivaste y markup de Product en una página que no es un producto.

Valida contra lo que puedes ver. Una estrella de rating en JSON-LD y ninguna valoración en la página es la forma en que se caen las reseñas.

7. HTTPS y las cabeceras aburridas

Vencimiento del SSL, el hostname correcto en el certificado, un TLS que no sea pieza de museo: Comprobador de certificado SSL. Después el Comprobador de cabeceras de seguridad y el Comprobador de cabeceras HTTP para HSTS, sorpresas de X-Robots-Tag, cabeceras de caché que le sirven un noindex viejo a Googlebot, y restos de contenido mixto después de un paso a HTTPS.

Esta sección es corta porque tiene que serlo. Si el certificado se muere el jueves, ese es todo el hallazgo.

8. Crawlers de IA, después de la base

Esto va al final a propósito. Un llms.txt bonito no ayuda a un sitio que está en noindex.

Decide, como persona, si quieres GPTBot, ClaudeBot, PerplexityBot y Google-Extended en el sitio. Después revisa que el robots.txt coincida con la decisión. El Comprobador de acceso para crawlers de IA es la pasada a nivel de URL. Si tienes logs, el Analizador de logs de bots de IA muestra quién llegó de verdad y quién recibió un 403.

llms.txt es documentación opcional para máquinas. No es un interruptor de ranking. La Puntuación GEO es una nota de preparación para ser citado en motores de respuesta: sirve como lista de pendientes, no como un número de vanidad para una diapositiva.

Si vendes la historia de que "estamos listos para la búsqueda con IA" mientras las páginas que generan dinero están bloqueadas, te vas a merecer el correo de seguimiento.

Cómo convertir esto en tickets

Una auditoría que nadie implementa es un PDF.

Separa lo que encontraste:

P0 — no se puede indexar o rastrear como se pretendía. Disallow en una sección en vivo. noindex en páginas que generan dinero. Canonicals a un 404. La home en 302. Corrígelo esta semana.
P1 — la plantilla está en el índice y igual está perdiendo. LCP fallido en producto. Cadenas de redirección en el blog viejo. Sitemap lleno de 301. Este sprint o el siguiente.
P2 — higiene. Alts que faltan en la página de nosotros. Un salto de más en una URL de campaña de 2019. Una cabecera que deberías agregar. Backlog.

Un ticket, un patrón de URL, una respuesta esperada. "Mejorar el SEO" no es un ticket. "noindex en /products/* que viene del X-Robots-Tag en el CDN, quítalo, confírmalo con una revisión de cabeceras" sí es un ticket.

Vuelve a revisar las mismas URLs después del deploy. Las auditorías que no vuelven a pegarle a la página en vivo son la forma en que el mismo noindex sobrevive tres sprints.

Qué no reemplaza esta checklist

Un kit de navegador no va a renderizar cada ruta de JavaScript de un catálogo de 400k URLs, y no va a reproducir desde disco un cuarto de los hits de Googlebot. Para eso sigues queriendo un crawler de escritorio y una muestra de logs.

Search Console sigue siendo la fuente de verdad de lo que hizo Google. Estas revisiones son cómo averiguas el porqué, sin esperar a que termine un rastreo ni pagar un asiento.

Corre la pasada completa cuando el sitio cambia de forma: rediseño, cambio de CMS, plantilla nueva, locale nuevo. Entre medio, mira el informe de Páginas y CWV una vez al mes. Si crece un motivo de "not indexed", o una plantilla pasa de Good a Needs improvement, esa es la siguiente auditoría. Ya sabes qué sección abrir.

Checklist de auditoría SEO técnico