Claude para SEO técnico: Audita el Repositorio, No el Crawl

Si busca cómo usar Claude para SEO técnico, el consejo que encontrará es siempre una variante del mismo movimiento: exporte un crawl, pegue las peores filas en una ventana de chat y pida a Claude que le diga qué hacer al respecto. Este flujo de trabajo trata a Claude como un lugar más inteligente para leer un informe de crawl — y desperdicia casi todo lo que el modelo realmente hace bien. El SEO técnico en un sitio moderno no es un problema de páginas renderizadas que resulta tener código detrás. Es código: reglas de robots, generación de sitemap, lógica de canonicals, metadatos, redirecciones y datos estructurados son todos archivos de código. El lugar correcto para Claude no está en el lado de salida del crawl. Está dentro del repositorio, donde puede leer los archivos que causan los síntomas que el crawl fotografía — y luego arreglarlos en la misma sesión, como un pull request que un humano revisa.

Esta guía es la rama técnico-SEO de nuestro pilar Claude para SEO. Cubre qué puede determinar Claude sobre su SEO técnico de forma estática — antes de que algo se crawle — la lista de verificación concreta archivo por archivo, cómo se distribuyen las correcciones como PRs, y la parte que casi todo flujo de trabajo de AI-SEO omite: verificar cada corrección en Search Console unos tres semanas después, para que «Claude lo arregló» se convierta en un claim medido en lugar de uno esperanzador. Una revelación honesta al inicio: la consulta que este artículo apunta registra esencialmente ningún volumen de búsqueda aún. La práctica está por delante de la demanda. Ese suele ser el mejor momento para escribir la guía.

El crawl encontró el síntoma. El repositorio contiene la causa

Un crawler funciona de afuera hacia adentro. Obtiene páginas renderizadas, muestrea lo que puede alcanzar y reporta síntomas: dos canonicals en conflicto aquí, una cadena de redirección allá, un grupo de páginas que falta del sitemap. Cada uno de esos síntomas tiene una causa, y en un sitio construido con framework la causa casi nunca está en la página — está en un template, un archivo de configuración o una rama de middleware. El crawler puede decirle que cien páginas tienen el canonical incorrecto. No puede decirle que los cien son renderizados por un archivo de layout con una línea mala, porque nunca ha visto el archivo de layout.

Claude ejecutándose dentro del repositorio comienza desde la causa. Lee el template y lo sabe — sin obtener ni una sola URL — que cada página que el template renderiza hereda el bug. Esa inversión cambia la economía de la auditoría dos veces. Cobertura: un crawler muestrea, pero una lectura de archivo es exhaustiva, porque una función generateMetadata es los metadatos de cada ruta que la usa. Velocidad: la primera pasada de una auditoría técnica en un sitio Next.js es leer quizás diez archivos, que Claude maneja en segundos, no en las horas que un crawl completo toma en un sitio grande.

En un sitio que auditamos, la ruta del sitemap hacía map sobre una colección de contenido que había sido reestructurada meses antes. El sitemap compiló, deployó y retornó un 200 válido — simplemente había dejado de incluir todas las páginas de un template. Un crawler no vio nada mal, porque cada página que alcanzó estaba bien; las que faltaban eran exactamente las que no tenía ruta para alcanzar. Leer app/sitemap.ts contra el árbol de rutas real superficializó el gap en una pasada. Esa es la categoría de bug para la que existe la auditoría repo-first: invisible desde afuera, una lectura de archivo desde adentro.

Un crawler reporta que cien páginas tienen el canonical incorrecto. El repositorio le muestra la línea, en un template, de la que los cien lo heredan — y Claude puede leer esa línea, arreglarla y abrir el PR en la misma sesión.

Qué puede leer Claude que un crawler no puede

En un sitio Next.js — y todo framework serio tiene equivalentes — el área de superficie de SEO técnico se concentra en una lista corta de archivos. Este es el mapa desde el que trabaja Claude, y cada archivo tiene una clase de fallo que es totalmente visible en source y en gran medida invisible en un crawl.

Observe qué une las filas enfatizadas: son bugs que pasan cada build, se despliegan sin error, y no producen defecto visible en ninguna página individual. Solo existen como una relación entre archivos — sitemap versus árbol de rutas, canonical versus origen — que es precisamente el tipo de razonamiento entre archivos para el que está construido un modelo de lenguaje con acceso a repositorio, y un crawler página por página no está.

La lista de verificación repo-first, archivo por archivo

Aquí está la pasada concreta, en el orden en que Claude debería ejecutarla — cada verificación emparejada con la condición de aprobación y la métrica de Search Console que verificará la corrección. La métrica se compromete cuando el finding se presenta, no después de que se envíe la corrección; esa disciplina, y por qué la versión más profunda de cinco capas de esta auditoría está estructurada como está, se cubren en la guía hermana sobre auditorías técnicas de SEO.

Dos hábitos hacen que esta lista funcione en la práctica. Primero, Claude debe leer los archivos como un sistema, no una lista — la verificación de redirección solo tiene sentido cuandonext.config redirecciones y middleware rewrites están compuestos juntos, y la verificación de canonical solo tiene sentido contra el origen en vivo. Segundo, cada finding debe archivarse antes de que se arregle algo, con su impacto esperado y métrica de verificación attached, para que la auditoría produzca una cola responsable en lugar de una tarde heroica de ediciones no registradas.

Las correcciones se envían como pull requests, no tickets

Aquí es donde el marco repo-first deja de ser una optimización de auditoría y se convierte en un modelo operativo diferente. En el flujo de trabajo crawler-y-chat, un finding se convierte en un ticket, el ticket espera a un desarrollador, el desarrollador re-deriva el contexto que la herramienta ya tenía, y la corrección llega semanas después — si llega. Cuando Claude ya está en el repositorio, la entidad que encontró el metadataBase faltante es la entidad que edita el archivo. La distancia entre diagnóstico y corrección colapsa de un sprint a un diff.

El punto de control no desaparece — se mueve a donde los equipos de software ya tienen uno: el pull request. Claude abre un PR con el finding, la evidencia y el cambio; un humano revisa y fusiona. Nada llega silenciosamente. Esto importa más en SEO técnico que casi en cualquier otro lado, porque los mismos archivos que pueden arreglar la indexación pueden destruirla — una regla de robots mala o una redirección incorrecta es un incidente en todo el sitio, y una corrección de canonical de una línea y una catástrofe de canonical de una línea se ven casi idénticas en un diff. El PR es la puerta de revisión humana, y produce algo que los tickets nunca hacen: un registro revisable con timestamp de exactamente qué cambió, que el paso de verificación está a punto de necesitar.

No está hecho hasta que Search Console lo diga

Un PR fusionado sigue siendo solo un claim. La corrección de robots debería restaurar impresiones en la sección bloqueada; la consolidación de canonical debería levantar la posición en la URL sobreviviente. Si lo hizo es un hecho que no existe hasta que Google recrawle, reprocese y acumule suficientes datos de query frescos para comparar — en la práctica, unos tres semanas. La mayoría de flujos de trabajo de SEO asistidos por IA terminan en la fusión y dejan que el claim se mantenga para siempre. Ese es el trabajo a medio hacer que todo este método existe para evitar.

La forma de trabajo es un board de tareas que cierra el loop. Cada finding de lista de verificación llega como una tarea llevando su métrica de verificación y target; el PR fusionado voltea la tarea a done con la URL del PR attached; y un monitor semanal re-lee Search Console en cualquier cosa pasada su fecha de verificación y anota el veredicto — confirmado, regresionado o inconcluso. Claude hace la lectura y la corrección; el board hace el recuerdo; Search Console hace el juzgado. La mecánica de ese loop — y por qué tres semanas es la física de la fuente de datos más que una elección de producto — son el sujeto de la guía hermana sobre SEO en loop cerrado.

Ejecute esto durante un trimestre y el subproducto se convierte en el activo: un registro por sitio de qué correcciones técnicas realmente verifican. Consolidaciones de canonical confirmando de forma confiable, trabajo de renderización leyendo inconcluso dos veces seguidas — la próxima pasada de auditoría comienza desde ese historial medido en lugar de una escala de severidad genérica, que es cómo el loop se vuelve más inteligente sobre un sitio en lugar de auditarlo desde cero para siempre.

Qué Claude no puede ver desde el repositorio

Repo-first es una gran parte de SEO técnico. No es todo, y pretender lo contrario rompería la regla de honestidad del método mismo. Tres puntos ciegos permanecen fuera del árbol de source no importa cuán bueno sea el modelo.

Lo que Google realmente hizo. El repositorio muestra intención; solo Search Console muestra resultado — qué se indexó, qué se muestra, qué gana clicks. La auditoría lee GSC a lo largo como el registro de la realidad, no solo en el tiempo de verificación. Lo que los usuarios reales experimentan. Core Web Vitals se juzgan en datos de campo en el percentil 75 de visitas reales. Claude puede detectar la imagen sin dimensionar y el script de bloqueo en source, pero el veredicto viene de medición de campo, y los scores de lab halagan a cada sitio. Lo que se sienta fuera del repositorio. Reglas de CDN, configuración edge, un reverse proxy que alguien configuró en 2021 — si no está en el árbol de source, una lectura de source no puede encontrarlo, y un crawl confirmando del sitio en vivo permanece como la verificación cruzada honesta de que lo que el código intenta es lo que el servidor sirve.

Cómo ejecutar esto en su propio sitio

La configuración es deliberadamente aburrida. Claude Code se ejecuta en su repositorio de sitio web — el mismo lugar donde sus desarrolladores ya trabajan — y se conecta sobre MCP a los datos que no puede conocer desde source: rendimiento de Search Console, el board de tareas compartido, y el fallback de crawl. La guía de conexión cubre la instalación de un comando. A partir de allí, el loop anterior es el manual operativo: lea los diez archivos, presente los findings con sus métricas de verificación, envíe las correcciones seleccionadas como PRs, y deje que el monitor semanal anote los veredictos.

Si quiere ver la mitad de búsqueda ejecutarse contra sus propios datos primero, el informe SEO gratuito conecta su Search Console y superficializa donde la capa técnica ya le está costando — las secciones mostradas pero nunca elegidas, las URLs compitiendo consigo mismas. Y si prefiere que todo el loop se ejecute como un servicio — findings presentados, PRs abiertos, veredictos leídos — reserve una llamada y le caminaremos a través de lo que se ve en su repositorio.