Cómo hago una auditoría SEO de un sitio web: pipeline completo

TL;DR

Hago la auditoría del sitio yo mismo, manualmente, con mis propios scripts y herramientas – la red neuronal solo participa en dos puntos específicos: ayuda a escribir el código de los scripts de recopilación de datos y organiza mis notas dispersas en un borrador legible del informe. Todo el análisis, la interpretación de métricas y la decisión de qué es crítico y qué puede esperar, es mi trabajo. A continuación, paso a paso: reconocimiento, tres bloques obligatorios para cualquier sitio, verificación profunda, una ola de comprobaciones adicionales según el tipo de negocio y el armado final del informe.

Después de mi última publicación en Telegram (suscríbanse, por cierto), empezaron a preguntarme: ¿realmente hago la auditoría yo mismo, manualmente, y no ejecuto algún script automático para copiar el resultado en mi informe? La pregunta es lógica – hoy en día se habla de automatización en SEO en cada esquina, y la palabra «auditoría» se ha asociado con un botón de «ejecutar» y una espera de cinco minutos. En mi caso es diferente, y ya que surgió la pregunta, voy a desglosar el proceso paso a paso – con nombres de scripts, lógica y lo que realmente obtengo al final de cada etapa.

Aclaro de inmediato el tema de la red neuronal, porque la pregunta es precisamente sobre eso. La uso en dos puntos. El primero: al escribir los scripts en Python que recopilan datos; el código se escribe más rápido si el borrador lo hace el modelo y luego lo corrijo y adapto a la tarea específica. El segundo punto: al final, cuando tengo decenas de notas, números y observaciones recopiladas manualmente durante el trabajo. Es una mezcla de pensamientos, un flujo de conciencia que hay que convertir en un informe legible – ahí el asistente organiza el texto en una estructura, y yo verifico cada hecho y ajusto las redacciones. El análisis del sitio, la decisión de qué revisar más a fondo, la priorización de hallazgos – todo eso lo hago yo, con mis ojos y mi cabeza, mirando los números que arrojan mis herramientas.

A continuación, detallo paso a paso en qué consiste mi auditoría. Doy los nombres de los scripts, pero no el código – eso, disculpen, es mi herramienta de trabajo, la que me da de comer. Se puede intentar armar un pipeline similar por cuenta propia, pero sin experiencia en análisis, un conjunto específico de scripts y números crudos darán poca utilidad. Los números sin interpretación son solo números.

Escribo de forma resumida donde se podría profundizar en detalles. Un desglose técnico detallado de cada script convertiría el artículo en un manual que leerían muy pocos. Por eso doy la lógica del proceso y lo que obtengo en cada paso, sin analizar los internos.

Paso 0. Reconocimiento

El primer paso de cualquier auditoría es entender con qué estoy trabajando. Sin esta etapa, se puede perder medio día en una verificación profunda de datos estructurados en un sitio que ni siquiera tiene un robots.txt normal.

El objetivo del reconocimiento es recopilar información y decidir qué verificaciones adicionales del paso 3 tiene sentido ejecutar. Si el sitio no es un negocio local, ¿para qué ejecutar esas comprobaciones? Si el sitio no tiene blog, ¿para qué analizar la canibalización de palabras clave?

Esto es lo que ejecuto en esta etapa y por qué:

Script / herramienta	Qué reviso	Qué obtengo
sitemap_discovery	Si existe sitemap.xml, robots.txt, cuántos mapas hay y de qué tipo	Comprensión de si secciones importantes del sitio están bloqueadas para indexación en robots, si hay sitemapindex (mapa de mapas para sitios grandes)
render_page --mode auto --json	Código HTML, tipo de renderizado, texto extraído, fecha de publicación	SPA (sitio que se arma en el navegador del usuario, no se entrega como HTML listo) o SSR clásico; si el texto está truncado – señal de que hay que verificar con curl
curl sobre un array de direcciones (/about, /pricing, /blog, /contacts y una dirección inexistente)	Códigos de respuesta, encabezados, tiempo hasta el primer byte, redirecciones	200 en páginas vivas, 404 en la inexistente, redirección correcta de http a https, si la compresión y el caché están activados
adv_crawl con límite de varios cientos de páginas	title, meta, h1, estado, redirecciones en una muestra de páginas	Distribución de estados de respuesta, duplicados de title y meta, páginas sin h1, discrepancia de canonical
adv_urls	Estructura de rutas y parámetros	Desglose por secciones del sitio, basura UTM en el índice, localización, posible canibalización
yandex_webmaster_list_hosts	Si el sitio está agregado en Yandex.Webmaster	Si no – primera recomendación en el informe: registrarlo
yandex_metrika_list_counters	Si el contador de Metrica está instalado	Si sí – luego extraigo de ahí las páginas principales y el tráfico para el análisis de texto
consulta de búsqueda por dominio excluyendo el propio dominio	Menciones externas, competidores	Quién escribe sobre el sitio, quién compite por la atención en los resultados de búsqueda

Al final de este paso, tengo una nota con señales básicas sobre el sitio – qué tipo de proyecto es, qué CMS usa, si hay problemas técnicos evidentes en la superficie, hacia dónde mirar más a fondo. A menudo ya aquí se ve la dirección: si curl muestra que la mitad del sitio devuelve 404 en páginas que realmente existen, la nota se convierte en la prioridad número uno del informe.

Paso 1. Núcleo: auditoría técnica, contenido y datos estructurados

Después del reconocimiento, paso a tres bloques que ejecuto casi siempre, independientemente del tipo de sitio. Es la base, sin la cual cualquier otro análisis queda en el aire.

Auditoría técnica

Aquí reviso todo lo que impide que los robots de búsqueda recorran y entiendan el sitio correctamente. Uso los mismos render_page y sitemap_discovery del paso anterior, además de adv_urls y verificación de seguridad de URL. Si en el reconocimiento ya hubo un crawl rápido, tomo sus resultados para no hacer consultas repetidas.

Analizo la accesibilidad de las páginas para el rastreo – si secciones importantes están bloqueadas en robots.txt o mediante la etiqueta noindex. Verifico la indexabilidad: si los enlaces canonical coinciden con la dirección real de la página, si hay duplicados de contenido, si hay páginas finas (páginas que los buscadores consideran innecesarias) con mínimo texto. Reviso los encabezados de seguridad del servidor, la estructura de URL y la lógica de redirecciones, la adaptabilidad a dispositivos móviles, el potencial de velocidad de carga, la dependencia del contenido del renderizado con JavaScript y el soporte de IndexNow (protocolo de notificación rápida a buscadores sobre cambios en el sitio).

Al final, obtengo una evaluación por cada categoría – si el sitio pasó la verificación o no, una puntuación técnica general de 0 a 100 y una lista de hallazgos clasificados por prioridad: crítico, alto, medio, bajo.

La mayoría de las veces, los problemas técnicos no están en lugares obvios como robots.txt, sino en detalles: un canonical que apunta a una versión inexistente de la página después de un cambio de dominio, o una cadena de redirecciones de tres o cuatro saltos donde debería haber una sola redirección directa.

Contenido y E-E-A-T

Luego reviso el contenido en sí. Aquí uso obligatoriamente un script separado para evaluar la calidad del texto en ruso – las herramientas universales de análisis de contenido a menudo simplemente no ven el cirílico y dan un resultado vacío donde hay mucho texto.

Evalúo según el modelo E-E-A-T (Experience, Expertise, Authoritativeness, Trust – experiencia del autor, experticia, autoridad de la fuente y confianza en el sitio), con pesos: experiencia – 20%, experticia – 25%, autoridad – 25%, confianza – 30%.

Reviso el volumen de texto en relación con el tipo de página (una ficha de producto y un artículo de blog requieren volúmenes diferentes), la legibilidad, signos de texto escrito por IA sin editar, señales YMYL (Your Money Your Life – páginas que afectan el dinero o la salud de las personas, para las cuales los requisitos son más estrictos: presencia de datos legales, descargos), y el potencial de citabilidad del texto en respuestas de servicios de IA.

Al final – una puntuación de contenido, desglose por E-E-A-T, evaluación de preparación para citas y banderas donde el texto es fino, de relleno (conjunto de palabras sin utilidad) o escrito con patrones de IA genéricos sin edición.

Datos estructurados

El tercer bloque es el marcado schema.org (el estándar sigue siendo muy relevante en 2026. Ayuda a los buscadores y a la IA a entender la estructura de la página: dónde está el precio, dónde la reseña, dónde el autor).

Reviso la validez de JSON-LD y microdata, la presencia de tipos de marcado obsoletos – FAQPage y HowTo, por ejemplo, los buscadores ya no los muestran en fragmentos enriquecidos, aunque formalmente el marcado sigue siendo válido. Verifico los campos obligatorios y qué oportunidades de marcado el sitio no está usando, aunque podría.

Al final – un desglose por bloques de marcado y escribo fragmentos JSON-LD listos que se pueden entregar directamente al desarrollador para su implementación.

Paso 2. Profundizo

Si el primer paso es la base, el segundo es una verificación más específica y técnica. Aquí hay cuatro direcciones, cada una con su particularidad.

Velocidad de carga y Core Web Vitals

Core Web Vitals (CWV) – un conjunto de métricas de Google que evalúan la experiencia real del usuario en la página: velocidad de aparición del contenido principal, velocidad de reacción a las acciones y estabilidad del diseño durante la carga.

Lo verifico a través de PageSpeed Insights y el historial de datos de CrUX (Chrome User Experience Report – datos reales de usuarios de Chrome, no mediciones de laboratorio). Además, desgloso los componentes de la métrica LCP (tiempo hasta renderizar el elemento visible más grande) para entender qué está ralentizando: el servidor, las fuentes, las imágenes o los scripts.

Si PageSpeed alcanza el límite de consultas y los datos de CrUX del sitio son insuficientes, cambio al análisis manual: una matriz de tiempos con curl más mediciones de laboratorio en el navegador. Es más lento, pero es importante obtener los datos de todos modos.

Reviso LCP, INP (retraso en la respuesta a la acción del usuario) y CLS (cuánto se desplazan los elementos durante la carga) según el percentil 75 de datos de campo (explico qué es esto más abajo) – este es el indicador que Google usa para el ranking, no los valores promedio. Luego, el tiempo hasta el primer byte, recursos que bloquean el renderizado, optimización de imágenes y carga de scripts de terceros.

Qué es el percentil 75

El promedio aritmético distorsiona la imagen: visitas raras con internet de gigabits o desde teléfonos antiguos desplazan el valor. El percentil elimina las anomalías.

El percentil 75 muestra: el 75% de las sesiones de visitantes reales se cargan más rápido o igual que la marca indicada. Si el percentil 75 de LCP es de 2,2 segundos, tres cuartas partes de todas las visitas al sitio entran en ese rango.

Al final – una puntuación de rendimiento, estado de cada métrica (si superó o no el umbral) y una lista de cuellos de botella específicos con el efecto esperado de su corrección.

Mapa del sitio

Por separado, analizo el sitemap.xml. Por alguna razón, cada vez se olvidan más de él, y es una lástima. El archivo es muy importante.

Verifico la validez de la estructura XML, la actualidad de las fechas de última modificación de las páginas (a menudo la fecha es la misma en todas las páginas – señal segura de que el mapa se genera automáticamente y nadie lo revisa), la cobertura de páginas vivas por el mapa del sitio y viceversa, los límites de 50 mil direcciones por archivo.

Para sitios con ubicaciones (por ejemplo, cadenas con sucursales), aplico umbrales más estrictos: si más de 30 páginas de ubicaciones requieren atención – advertencia; más de 50 – parada forzosa y análisis antes de continuar la auditoría, porque a esa escala, un error en la plantilla se multiplica en cientos de páginas.

Al final – informe de validación, puntuación del mapa del sitio y lista de páginas que faltan en el mapa o, por el contrario, están incluidas por error.

Verificación visual y móvil

Aquí voy al sitio manualmente y reviso las versiones de escritorio y móvil, y la versión móvil la veo específicamente con el User-Agent cambiado a iPhone – algunos sitios entregan un diseño diferente según quién los visita, y sin cambiar el agente no se puede ver la imagen móvil real.

Reviso la primera pantalla sin scroll: si se ve el encabezado H1, si hay un botón de acción (CTA), si algo tapa el bloque visual principal. Miro el tamaño de la fuente – menos de 12-14 píxeles es incómodo de leer desde el teléfono. Verifico el tamaño de las zonas táctiles para botones – menos de 44 píxeles es un error. Busco desplazamiento horizontal en la versión móvil, imágenes sin dimensiones definidas (lo que hace que la página se mueva al cargar) y superposición de elementos entre sí.

Al final – un veredicto sobre la adaptabilidad móvil basado en hechos concretos, no en una impresión general, y una puntuación visual.

Registros del servidor

Este bloque solo lo hago si el cliente da acceso a los registros del servidor – sin eso no hay nada que analizar. Pero si hay acceso, es quizás la parte más valiosa de la auditoría, porque muestra lo que no se ve ni en Search Console ni en Metrica.

Reviso el gasto real del presupuesto de rastreo – qué porcentaje de solicitudes al servidor provienen de Googlebot y YandexBot, qué páginas visitan los bots con más frecuencia, cuáles ignoran. Busco errores 404 en los registros que no aparecen en los informes de los buscadores – a menudo son enlaces antiguos por los que todavía entra alguien. Miro la carga de transiciones y solicitudes no estándar a rutas como /.env o /login – eso ya es un problema de seguridad, no solo de SEO.

Paso 3. Ola según indicadores

El paso 0 determina qué verificaciones adicionales tiene sentido ejecutar. Analizar la canibalización de palabras clave en un sitio web de tarjeta de presentación de cinco páginas es pérdida de tiempo. Por eso, el paso 3 es un conjunto de módulos que se activan de forma puntual, según los desencadenantes del reconocimiento.

Preparación para citas en servicios de IA

Este módulo lo ejecuto casi siempre, porque casi cualquier propietario de un sitio en 2026 debería estar interesado en que su contenido sea mencionado en las respuestas de ChatGPT, Perplexity y en los resultados de IA de los buscadores. Reviso el robots.txt para ver si está permitido el acceso a los bots de estos servicios – GPTBot, OAI-SearchBot, ClaudeBot, PerplexityBot.

Miro el archivo llms.txt – aquí es importante: este archivo no es una palanca de influencia, porque los grandes buscadores simplemente lo ignoran al generar respuestas. Tiene más peso qué tan citable es el texto de la página por su estructura: los fragmentos cortos y completos en el rango de 130-170 palabras son mejor extraídos por el modelo en su forma pura que los párrafos largos con múltiples ideas anidadas. Además, reviso las señales de autoridad de la marca – menciones en Wikipedia, Reddit, VC.ru, Habr, Dvach (me da risa, pero para el contenido en ruso, para la IA es casi como Reddit para el resto del mundo), Pikabu y, por supuesto, YouTube.

Al final – una puntuación de preparación en varias dimensiones y evaluaciones separadas por plataformas: cómo es probable que el sitio sea presentado en las vistas generales de Google, en las respuestas de ChatGPT y en Perplexity.

Perfil de enlaces entrantes

Los backlinks los verifico en cascada de fuentes – primero el rápido y gratuito CommonCrawl, si no proporciona suficientes datos, entonces la API paga de ahrefs. Además, datos de Webmaster y Search Console.

Luego cruzo los datos de diferentes fuentes entre sí y verifico la vigencia de los enlaces con un script separado – un enlace muerto a un sitio que ya no existe no aporta beneficio, es peso muerto y lastre.

Reviso la cantidad de dominios únicos que enlazan al sitio, la distribución por autoridad de esos dominios, la naturalidad del texto ancla (si el 80% de los enlaces tienen la misma frase, es sospechoso), la proporción de enlaces tóxicos, la relación entre enlaces follow y nofollow, la relevancia geográfica de los donantes.

Canibalización y estructura de contenido

Este bloque lo activo si el sitio tiene un blog o una estructura de artículos pilar. Recojo el núcleo semántico, analizo los textos, busco canibalización de palabras clave, páginas en la zona «casi en el top» (posiciones 4 a 20), la brecha entre el title de la página y las palabras clave por las que realmente se posiciona, y la cuota de voz (share of voice) a través de la curva de CTR por posiciones.

Al final – un plan por clústeres de consultas, estructura de «hub y satélites» y análisis de casos concretos de canibalización con recomendación de qué página dejar como prioritaria.

Tienda online

Para sitios con fichas de productos, ejecuto verificaciones separadas. Reviso la validez del marcado de productos, los tamaños de las imágenes de las fichas, la búsqueda de errores 404 ocultos (cuando la página devuelve 200 pero el contenido es genérico, como si el producto no existiera), doble H1 en la página, metaetiquetas genéricas sin personalización, ausencia de bloque de productos similares, verificación del archivo price.xml – puede estar permitido en robots.txt pero no existir físicamente en el servidor.

Al final – una puntuación de comercio electrónico y análisis de fichas concretas con hallazgos.

Multilingüismo y datos de GSC/GA4

Si el sitio funciona en varios idiomas o locales – verifico hreflang (atributo que indica al buscador qué versión de idioma de la página es para qué audiencia). Si el cliente tiene acceso a Google Search Console y Google Analytics 4: reviso las consultas, verifico la indexación de URL específicas, extraigo informes de tráfico. Sin acceso a estos servicios, esta parte simplemente no se ejecuta – no tiene sentido adivinar con datos de otros.

Paso 3.5. Analítica de texto: solo en páginas con tráfico

Separo la analítica de texto porque aquí tengo una regla estricta: no ejecutarla en todo el sitio por completo. No tiene sentido: si una página no recibe tráfico y no está en el top de consultas, analizar la frecuencia de palabras en ella no aporta nada para la priorización.

Tomo la lista de páginas del informe de consultas de búsqueda de Google Search Console o del top de páginas visitadas según datos de Metrica. En estas páginas calculo la frecuencia de palabras y bigramas – pares de palabras consecutivas.

El sentido de este paso es simple: por el perfil de frecuencia de la página se ve bajo qué clústeres semánticos está realmente escrita, si hay un sesgo hacia la inserción de palabras clave sin contexto orgánico, si hay relleno evidente – palabras de relleno que aumentan el volumen del texto sin beneficio para el lector.

Al final – un perfil de frecuencia para cada página del top, que alimenta el bloque de contenido de la auditoría del paso 1. A menudo aquí surge una discrepancia: la página está formalmente escrita «para la consulta», pero de hecho el enfoque del texto está desplazado a un tema relacionado, y la frase objetivo se menciona una vez en el primer párrafo y no vuelve a aparecer.

Paso 4. Síntesis: cómo de una docena de informes sale un solo documento

Aquí comienza la parte principal de mi trabajo – no ejecutar scripts, sino ensamblar el resultado en un documento único que se pueda leer y sobre el cual se pueda actuar.

Leo las versiones completas de todos los informes intermedios de los scripts. Armo el documento final: una tabla resumen de puntuaciones de 0 a 100 por cada área de la auditoría y un plan de acción dividido en tres niveles – crítico, advertencia, superado con éxito.

Por separado, verifico cualquier mención de cambios recientes en algoritmos y requisitos de los buscadores según la lista actual de fuentes primarias, que mantengo actualizada – cada hecho en el informe está respaldado por un enlace a la página específica de donde se tomó.

El informe listo lo guardo en un formato más o menos estructurado y lo paso por LLM.

¿Cuánto tiempo lleva y qué recibe el cliente?

Todo el pipeline, desde el reconocimiento hasta el informe final, según mi experiencia, toma desde unas horas hasta un par de días – depende del tamaño del sitio, la cantidad de módulos que se activaron en el paso 0 y si hay acceso a los registros del servidor y servicios de análisis. Un sitio web de tarjeta de presentación de una docena de páginas pasa rápido por los tres bloques obligatorios. Una gran tienda online con blog, puntos de recogida e historial de auditorías previas – ya son tiempos muy diferentes.

Al final, el cliente no recibe una lista de veinte puntos «hagan esto mejor» con copia y pega de Lighthouse, sino un documento con puntuaciones por cada área, un plan de acción priorizado y, para cada punto, la base, las dependencias, el criterio de fallo y la métrica para monitoreo. Es la diferencia entre «su sitio es lento» y «el LCP supera los 4 segundos debido a imágenes sin comprimir en el encabezado; el efecto esperado después de la compresión es volver a la zona verde según el percentil 75 en unas semanas».

Si después de este análisis quedan dudas, puedo ejecutar todo el escenario en vivo en un dominio concreto; tengo las herramientas a mano. Envíen la dirección del sitio, el análisis será con números reales, no con ejemplos abstractos del artículo.