Cómo mejorar el SEO de tu página web paso a paso

Lo que vas a lograr

Una auditoría le puso 75 sobre 100 a mi propio sitio. Peor: busqué en Google el servicio exacto que vendo, en mi propia ciudad, y no aparecía. Ni en la primera página ni en la tercera.

Arreglé cada cosa, anoté lo que funcionó y lo que me costó tiempo, y lo empaqueté en este skill. Estos son los números finales, medidos en producción sobre este mismo sitio que estás leyendo:

• PageSpeed escritorio: 92 → 100. Móvil: 77 → 91.
• Salto de contenido (CLS): 0.137 → 0. Cero exacto, no redondeado.
• Fuentes: 273 KB → 123 KB. Un 55% menos.
• Carga completa: 1.166 ms → 734 ms.
• 102 de 102 URLs con título y descripción dentro de norma.

Puedes abrir PageSpeed Insights, poner chiragx.com y comprobarlo ahora mismo. No te pido que me creas.

Antes de empezar: instala el skill

Es un skill de Claude Code. Descomprime la carpeta dentro de tus skills:

~/.claude/skills/web-playbook-100/

En Windows es C:\Users\TU-USUARIO\.claude\skills\. Se activa solo cuando le pidas auditar o mejorar el SEO de un sitio.

¿No usas Claude Code? Igual te sirve. Todo es Markdown y los scripts corren solos desde la terminal. Abre SKILL.md y léelo como el manual que es.

Cómo pedírselo a Claude para que haga casi todo solo

El skill se activa cuando le hablas de SEO, PageSpeed, Core Web Vitals, fuentes, imágenes o de "por qué no aparezco en Google". Para no depender de eso, nómbralo: usa el skill web-playbook-100. Y dale estas cuatro cosas en la primera frase, porque sin ellas tiene que preguntar:

1. La URL y las rutas por idioma (/es/, /en/).
2. Dónde está alojado y qué puedes tocar. Cloudflare, WordPress, Shopify, un HTML estático. Y qué no puedes tocar.
3. Qué quieres primero: medir y proponer, o aplicar. Lo sano es "mide, propone, no cambies nada hasta que yo apruebe", y después "aplica los cambios 1 a 3 y vuelve a medir con el mismo comando".
4. Los accesos como variables de entorno, nunca pegados en el chat. Un token de Cloudflare con el permiso justo, la clave de la API de PageSpeed. Los creas tú y los revocas tú al terminar.

Un cambio, una medición. Pide siempre el antes y el después con el mismo comando, y que te diga qué no pudo verificar. El prompt con el que arranco cualquier sitio:

Usa el skill web-playbook-100. Mi sitio es https://midominio.com, rutas /es/ y /en/,
alojado en [Cloudflare / WordPress / ...]. Corre scripts/audit.sh con --sitemap y dame
las brechas ordenadas por impacto según el skill, con el comando con el que comprobaste
cada una. No cambies nada todavía.

En cada paso te dejo el prompt exacto, lo que Claude hace solo y lo que sigue siendo tuyo. Al final está la lista completa de lo que nadie puede hacer por ti.

Paso 1. Mide de verdad, no como te gustaría

Casi todo el mundo se salta este paso y por eso arregla lo que no era. Antes de tocar una línea:

1. Abre tu sitio en el celular con datos, no con wifi. El wifi de tu oficina te miente. Tus clientes te visitan en la calle.
2. Corre PageSpeed en móvil tres veces y toma el valor del medio. Una sola medición no dice nada; varía demasiado. Escritorio casi siempre se ve bien y casi nunca es donde te visitan.
3. Busca en Google tu servicio + tu ciudad, en incógnito. Si no apareces, ese es tu problema real, no el score.
4. Cuenta tus servicios y cuenta tus páginas. Si ofreces cinco cosas y tienes una sola página, ahí está tu techo. Guarda ese número.

Apunta los cuatro resultados en un archivo. Al final vas a volver a medir con lo mismo, y ahí es donde ves si sirvió.

El script scripts/audit.sh del skill hace la parte técnica de esto por ti: con --sitemap revisa códigos de respuesta, redirecciones, canonicals, hreflang y metadatos de todas las URLs de tu sitemap de un tirón, y además comprueba que obligas HTTPS, qué cabeceras mandas y qué dice tu robots.txt de cada rastreador de IA. Y scripts/psi.js corre PageSpeed tres veces, saca la mediana y te lista lo que se pide antes del LCP.

Pídeselo así:

Mide https://midominio.com/es/ con scripts/psi.js tres veces en móvil (PSI_KEY está en el
entorno), corre los bloques 1 a 3 de scripts/browser-audit.js en la página y guarda todo
en medicion-inicial.md. No cambies nada.

Lo que hace solo: PageSpeed con mediana, la lista de lo que se carga antes del LCP, CLS y LCP en navegador real y la batería de curl. Lo que te toca a ti: sacar la clave gratuita de la API de PageSpeed (cinco minutos, con tu cuenta de Google), abrir el sitio en tu teléfono con datos, buscar tu servicio más tu ciudad en incógnito desde tu ciudad, y contar tus servicios.

Paso 2. Una página por servicio, no una lista en el home

Este fue el cambio que más movió la aguja, y no tiene nada de técnico.

Si vendes cinco servicios y los tienes como cinco párrafos dentro del home, Google tiene una página para posicionar en cinco búsquedas distintas. Va a perder las cinco. Cada servicio necesita su propia URL, con su propio título, su propia descripción y su propio contenido de verdad.

En mi caso pasé de un home con una sección de servicios a doce páginas (seis servicios en dos idiomas), cada una con:

• Un título que usa las palabras que la gente escribe, no las que usamos en la industria.
• Un problema concreto arriba, antes de hablar de mí.
• Preguntas frecuentes reales, las que me hacen en las llamadas.
• Datos estructurados de tipo Service y FAQPage.
• Enlaces cruzados entre servicios relacionados, y de vuelta al índice.

El skill trae esto en references/arquitectura.md, con el criterio para decidir qué merece página propia y qué no. Regla corta: si alguien podría buscarlo por su nombre, merece página.

Pídeselo así:

Estos son mis servicios: [lista]. Con references/arquitectura.md dime cuáles merecen URL
propia, propón slug en español e inglés, título de hasta 60 caracteres y descripción de
hasta 158 para cada uno, y la estructura de secciones. Redacta solo cuando te dé precios,
preguntas reales de clientes y casos.

Lo que hace solo: decidir qué merece página, proponer slugs, metadatos y estructura, redactar, y enlazar los silos en las dos direcciones si tiene tu código. Lo que te toca a ti: los hechos (precios, rangos, las preguntas que te hacen de verdad, casos con cifras), aprobar cada texto y, si usas un constructor visual, crear las páginas a mano.

Paso 3. SEO técnico: que Google pueda leerte sin adivinar

Aquí es donde la mayoría de los sitios pierden puntos por cosas invisibles. El orden que funciona:

1. Datos estructurados. Marca quién eres (Person u Organization), qué vendes (Service), tus preguntas (FAQPage) y la ruta de navegación (BreadcrumbList). Valida cada página en la prueba de resultados enriquecidos.
2. Canonical en todas las páginas. Una sola versión oficial de cada URL.
3. Hreflang si tienes más de un idioma. Recíproco: si la española apunta a la inglesa, la inglesa tiene que apuntar de vuelta. Si falla una, fallan las dos.
4. Sitemap generado solo, con lastmod real. Un sitemap escrito a mano se queda viejo en dos semanas.
5. Títulos y descripciones dentro de norma. Título hasta 60 caracteres, descripción hasta 158. Si se pasan, Google los corta y pierdes el mensaje.

Cuando esto esté listo, verifica el sitio en Google Search Console, sube el sitemap y pide la indexación de las páginas nuevas. También date de alta en Bing Webmaster Tools: es media hora y es de donde sale buena parte de lo que responden los buscadores con IA.

Search Console tiene su curva y hay decisiones que dependen de cómo esté armado tu sitio. Lo dejo mencionado como paso porque explicarlo bien es una conversación, no un párrafo. Escríbeme y lo vemos con tu caso en la mano.

Y una que casi nadie revisa: que el sitio obligue a HTTPS

Tener certificado no es lo mismo que obligar a usarlo. Puedes tener el candado y que http://tudominio.com siga sirviendo la página entera sin cifrar, con respuesta 200 y sin redirigir a ninguna parte. Pasa más de lo que crees, y lo compruebas en un segundo:

curl -sIL http://tudominio.com | grep -i "^HTTP/\|^location:"

Si en esa cadena no aparece un salto a https://, tienes tres problemas a la vez. Uno: el formulario de contacto de tu web viaja sin cifrar. Dos: los enlaces viejos que te apuntan a http://www. quedan contados como una URL distinta, así que la autoridad que te mandan se reparte en vez de sumarse. Y tres, el que nadie asocia: cada redirección extra cuesta tiempo de carga en móvil. En una medición real que hice, la cadena de saltos se estaba comiendo 0,61 segundos del renderizado.

En Cloudflare es un interruptor: SSL/TLS → Edge Certificates → Always Use HTTPS. Si no usas Cloudflare, es una regla de redirección 301 en tu servidor.

Ya que estás ahí, mira si mandas alguna cabecera de seguridad. Lo normal es que no mandes ninguna. Con un archivo _headers (o el equivalente de tu hosting) pones el mínimo sensato:

/*
  X-Content-Type-Options: nosniff
  Referrer-Policy: strict-origin-when-cross-origin
  X-Frame-Options: SAMEORIGIN

De HSTS te aviso: obliga al navegador a recordar durante meses que tu sitio solo va por HTTPS. Es bueno, pero si algo se te rompe no puedes deshacerlo rápido porque la orden ya está guardada en el navegador de cada visitante. Actívalo cuando el resto esté estable, no el primer día.

Pídeselo así:

Arregla canonical, hreflang recíproco con x-default, sitemap con lastmod real y los
títulos y descripciones fuera de norma en [mi código / mi plantilla]. Genera el JSON-LD
por plantilla y comprueba que parsea. Comprueba HTTPS forzado y cabeceras. Antes y
después con scripts/audit.sh --sitemap.

Lo que hace solo: todo lo que vive en el código o la plantilla, y la comprobación desde fuera. Con un token de Cloudflare, también el interruptor de HTTPS y las cabeceras. Lo que te toca a ti: verificar el sitio en Search Console y en Bing Webmaster Tools, subir el sitemap, pedir la indexación URL por URL (Google da una cuota diaria pequeña), decidir HSTS y, sin token, tocar los interruptores de tu hosting.

Paso 4. Rendimiento: lo que de verdad mueve el número

Esta es la parte con más mito por metro cuadrado. Lo que sí funcionó, en orden de impacto:

Fuentes

Google Fonts te cuesta una conexión a otro dominio antes de poder pintar una letra. Bájalas y sírvelas tú. Dos avisos que me costaron tiempo:

• Google sirve un solo archivo variable por familia. Si bajas "regular", "medium" y "bold" por separado, estás bajando el mismo archivo tres veces. Deduplica por hash y declara rangos de peso.
• Usa font-display: optional en la fuente del cuerpo. Con swap el texto se repinta y ahí nace buena parte de tu salto de contenido. swap solo es aceptable si ya ajustaste el respaldo con métricas medidas (el bloque 5 de browser-audit.js las calcula): entonces el texto se repinta pero no se mueve.

scripts/selfhost-fonts.js hace la bajada y la deduplicación solo.

Imágenes

• Convierte a AVIF y sirve con <picture>, dejando el original como respaldo. Mi home pasó de 1.013 KB a 533 KB sin que se note diferencia a la vista.
• Declara ancho y alto en todas las imágenes. Sin eso, el navegador no sabe cuánto espacio reservar y el contenido salta.
• Si tienes una regla global img{max-width:100%}, tiene que llevar height:auto. Sin eso las imágenes se aplastan. Este error estuvo semanas en mi sitio y lo vine a ver en una grabación de pantalla.

Salto de contenido

Llegar a cero es cuestión de reservar espacio: dimensiones en imágenes, alturas en lo que carga después, y nada que se mueva cuando entra la fuente. El script scripts/browser-audit.js te mide el salto, el elemento más grande y el contraste real en un navegador de verdad, que es distinto de lo que reporta un laboratorio.

Sirve la imagen del tamaño en que se ve, no solo en el formato correcto

Convertir a AVIF no basta. Un archivo de 1000px de ancho metido en un hueco que mide 340px sigue mandando el triple de píxeles de los que se ven. PageSpeed lo reporta como Improve image delivery y te dice exactamente cuánto sobra.

La regla es simple: mira el ancho real en pantalla, multiplícalo por dos (por las pantallas de alta densidad) y genera esa variante. Hueco de 340px, archivo de 700px. En mi propio sitio eso era una sola imagen sobrando 23 KiB.

ffmpeg -i original.jpg -vf "scale=-2:868:flags=lanczos" -q:v 3 medio.jpg
ffmpeg -i medio.jpg -c:v libaom-av1 -crf 34 -cpu-used 6 -still-picture 1 medio.avif

Y una que se paga cara: si cambias el contenido de una imagen, cámbiale el nombre. Las imágenes suelen servirse con caché de treinta días. Si reescribes el mismo archivo, todo el que ya lo había visto sigue viendo el viejo durante un mes, y tú lo das por corregido.

Los fondos CSS no son perezosos, y eso te cuesta el LCP en móvil

loading="lazy" solo existe para <img>. Cualquier background-image, inline o en CSS, se pide en cuanto el elemento existe, esté donde esté. En mi home eran veinte fondos de tarjetas (eventos, portadas, miniaturas de YouTube) a varias pantallas del pliegue: 642 KB de imágenes pedidas antes del LCP, compitiendo en un 4G lento con el texto del hero. Resultado: el párrafo principal tardaba 3,5 s en pintarse teniendo su HTML listo desde el medio segundo.

Lo primero que probé, content-visibility: auto en las secciones lejanas, no lo evita: Chrome deja de pintar la sección, pero sigue descargando sus fondos. Lo comprobé en el trace. Descártalo para esto.

Lo que sí funciona es no declarar el fondo hasta que hace falta: la declaración va en un atributo data-bg y un script de diez líneas la pasa a style cuando el elemento se acerca al viewport. Con un comprobador por scroll, como el de las animaciones de entrada, que no depende de que IntersectionObserver se ejecute:

<div class="event-img" data-bg="background-image:url('/images/evento.jpg')"></div>

(function(){var els=[].slice.call(document.querySelectorAll('[data-bg]'));var t=null;
function apply(el){el.style.cssText+=';'+el.getAttribute('data-bg');el.removeAttribute('data-bg');}
function check(){t=null;var h=window.innerHeight+600;
  els=els.filter(function(el){var r=el.getBoundingClientRect();
    if(r.bottom>-600&&r.top<h){apply(el);return false;}return true;});}
function onS(){if(!t)t=setTimeout(check,80);}
window.addEventListener('scroll',onS,{passive:true});window.addEventListener('resize',onS);
window.addEventListener('load',check);check();})();

Si las tarjetas las genera tu servidor, el cambio va en la plantilla y el script en el pie común, para que todas las páginas lo tengan. Con eso, lo que se pide antes del LCP bajó de 958 KB a 434 KB. En PageSpeed de Google: móvil de 88 a 91 con LCP de 3,5 s a 3,2 s y CLS 0; escritorio 99 con LCP 0,7 s. (En Lighthouse local da 95 y 2,4 s; la red que simula Google es más lenta, y ese es el número que cuenta.)

La forma de encontrar esto no es adivinar: en el JSON de Lighthouse, lista las peticiones cuyo inicio es anterior al LCP y ordénalas por peso. Ahí sale, en la primera pantalla, qué le está robando el ancho de banda al elemento que importa.

El contraste puede fallar en un tema y pasar en el otro

Si tu sitio tiene modo claro y oscuro tienes dos paletas, y la auditoría mide una sola: la que sirves por defecto. Un mismo color me daba 6,16 en oscuro y 4,47 en claro. El mínimo para texto pequeño es 4,5. Por tres centésimas sale marcado en rojo.

Revisa los dos temas antes de dar por buena la accesibilidad. En el navegador, forzando el esquema y midiendo el color calculado contra su fondo real.

Un aviso de método: no te fíes de un barrido automático propio. Si el texto va encima de una imagen o un degradado, calcular el contraste contra el color de fondo del contenedor da números inventados. A mí un script así me sacó treinta y un fallos, de los que uno era real. Para esto, la lista que te da Lighthouse es la fuente buena; tu script sirve para confirmarla, no para sustituirla.

Pídeselo así:

Fuentes: corre scripts/selfhost-fonts.js con mi URL de Google Fonts, sustituye las
etiquetas externas por @font-face locales con rangos de peso y calcula los respaldos con
el bloque 5 de browser-audit.js. Imágenes: scripts/to-avif.sh sobre /images, picture con
respaldo, width y height, y data-bg para los fondos fuera del primer pliegue. Un cambio por
despliegue, y CLS y LCP en navegador después de cada uno.

Lo que hace solo: fuentes, respaldos con métricas medidas, AVIF, dimensiones, fondos perezosos, contraste desde los tokens y la medición. Lo que te toca a ti: aprobar cada despliegue y mirar el sitio en tu teléfono después de cada uno, porque el número no ve si algo quedó feo. Y los ajustes del CDN si no diste token.

Paso 5. Entidad: que Google sepa que existes como persona o empresa

Esto es lo que casi nadie hace y es lo que separa "una web más" de "el referente del tema en tu país".

Google no solo indexa páginas, mantiene un grafo de entidades: personas, empresas, lugares y cómo se relacionan. Si tú no eres una entidad para Google, compites solo por palabras. Si lo eres, compites por ser quien eres.

Los pasos, en orden:

1. Marca Person u Organization en tu sitio con un @id estable, y referencia ese mismo @id desde todas las páginas.
2. Enlaza con sameAs a tus perfiles reales: LinkedIn, GitHub, YouTube, X, tu ficha de empresa.
3. Que todos esos perfiles digan lo mismo. Misma descripción, mismo nombre, mismo enlace. Si tu LinkedIn dice una cosa y tu web otra, estás mandando señales que se contradicen.
4. Si tienes cobertura de prensa, charlas, o entidades ya existentes que te mencionen, crea tu ficha en Wikidata y conéctala a tus empresas.

Lo de Wikidata tiene reglas de notabilidad y se puede borrar si lo haces mal, así que no lo tomes a la ligera. Está en references/entidad.md con el detalle, pero si vas a hacerlo para tu negocio, háblame antes y te digo si calificas y cómo plantearlo.

Pídeselo así:

Genera el bloque Person u Organization con @id estable y sameAs con estos perfiles:
[lista]. Ponlo en todas las plantillas referenciado por @id. Redacta una descripción de
hasta 150 caracteres que sirva igual en Instagram, X, LinkedIn, YouTube y Facebook. Busca
fuentes independientes sobre mí y dime si califico para Wikidata y con qué referencias.

Lo que hace solo: el schema, la descripción y el borrador de la ficha con sus fuentes. Lo que te toca a ti: editar cada perfil social con tu sesión, crear el ítem de Wikidata con tu cuenta y responder si lo cuestionan, sugerir el cambio en el panel de Google y reclamar tu perfil de empresa.

Paso 6. Contenido y medición: que esto no se muera en un mes

Un sitio en 100 que no publica nada vuelve a bajar. Necesitas dos cosas.

Un lugar donde publicar sin tocar código. Yo monté un CMS propio sobre Cloudflare porque quería controlar el HTML que sale, pero cualquier cosa sirve mientras publiques de verdad. Lo importante es que subir un artículo te tome quince minutos, no una tarde: si te cuesta, no lo vas a hacer. El montaje está en references/stack.md y references/cms-y-contenido.md.

Saber de dónde viene la gente. Mide el primer contacto, no el último: si alguien te encontró por Google en marzo y te escribió por WhatsApp en mayo, eso fue Google, no WhatsApp. Guarda el origen en el navegador la primera vez y mándalo con el formulario. Sin esto vas a estar adivinando qué canal te trae clientes.

Pídeselo así:

Monta la captura de primer contacto (utm_source, utm_medium, utm_campaign, referrer,
página de entrada y fecha) guardada en el navegador y enviada con el formulario. Genera mis
enlaces con UTM para [canales]. Propón un calendario de artículos: dos de intención de
compra por cada uno de coyuntura, con el título de búsqueda de cada uno.

Lo que hace solo: el código de atribución, los enlaces con UTM, el calendario y los borradores. Lo que te toca a ti: conectar el CRM o el correo donde caen los leads, usar los enlaces con UTM de verdad en cada canal, publicar con ritmo y aprobar cada artículo. La experiencia es tuya; nadie la inventa por ti.

Paso 7. Los enlaces: por qué "tengo 112 backlinks" puede significar cero

Este es el paso que más gente se salta, y el único donde no puedes hacer trampa.

Te va a pasar esto: corres una auditoría, te dice que tienes cien y pico de enlaces entrantes de treinta dominios, y te sientes bien. Después miras la lista y te encuentras dominios como .sbs, .cfd, .icu, .party, .monster, con títulos tipo "seo domain research", "Domain Report" o "URL Shared", casi todos alojados en Finlandia o Francia.

Esos no son enlaces. Son basura automática. Se generan solas cada vez que alguien mete tu dominio en una herramienta de análisis: la herramienta publica una página con el resultado, y esa página te enlaza. Correr auditorías las fabrica. No te hacen daño, porque los buscadores las ignoran, pero tampoco te suman nada, y te dan una sensación falsa de que ya tienes enlaces.

Cómo distinguir uno bueno de uno malo, sin herramienta de pago:

• ¿Un humano escribió esa página? Si el título es "Domain Report" o un número, no.
• ¿El texto del enlace dice algo? "chiragx.com" repetido cien veces es automático. "Perfil del fundador" lo escribió alguien.
• ¿Tiene sentido que ese sitio te mencione? Un organizador de eventos donde diste una charla, sí. Un acortador de URLs estonio, no.

Y ahora lo que sí funciona, en orden de facilidad:

1. Tus propias propiedades. Si tienes varias empresas, marcas o proyectos con web, revisa cuáles te enlazan de vuelta. En mi caso, de cinco empresas mías, tres no me enlazaban: mi web les mandaba autoridad y no recibía nada. Es el enlace más fácil que existe y no cuesta un centavo.
2. Los sitios donde ya apareciste. Eventos donde fuiste ponente, podcasts, clientes con página de casos, asociaciones. Muchos ya te mencionan sin enlazarte, o te enlazan mal. Un mensaje y listo.
3. Revisa cómo te enlazan los que ya lo hacen. Esto casi nadie lo hace y es dinero tirado. Un organizador me tenía puesto como http://www.midominio.com: sin cifrar, con www y con dos redirecciones antes de llegar. El enlace estaba, pero llegaba a una URL que no era la buena. Pedir que lo cambien a la versión correcta es un mensaje de dos líneas.
4. Socios y aliados. Si tú los tienes en tu web, es razonable pedir reciprocidad.

Lo que no te recomiendo: comprar enlaces, intercambiarlos en masa, o pagar por "500 backlinks garantizados". Eso construye exactamente el perfil que acabo de describir como basura, y encima pagando.

Una nota de expectativas: esto es lento y no lo arregla una tarde. Es el único paso de esta guía que depende de otras personas, y por eso es el que más gente abandona.

Pídeselo así:

Aquí está la lista de backlinks de mi auditoría: [pegada o CSV]. Sepárala en reales y
automáticos con los criterios del skill. Después corre scripts/enlaces.sh con mi dominio,
mi marca y estas URLs donde aparezco: [lista]. Redacta el mensaje de dos líneas para cada
corrección.

Lo que hace solo: separar la lista, comprobar cómo te enlaza cada página (sin cifrar, con www, con saltos, con nofollow) y quién te menciona sin enlazar, redactar los mensajes y corregir los enlaces en tus propias propiedades si tiene acceso. Lo que te toca a ti: enviar cada mensaje, pedir reciprocidad a tus socios y esperar. Es el único paso que depende de otras personas.

Paso 8. Que las IAs también te lean

Cada vez más gente no busca: pregunta. A ChatGPT, a Claude, a Gemini, o al resumen que Google pone arriba. Si tu web está afinada para el buscador clásico pero los modelos no te pueden leer, desapareces de la mitad de las consultas sin enterarte.

La buena noticia es que casi todo el trabajo ya lo hiciste en los pasos 3 y 5. Falta poco:

1. Que tu contenido esté en el HTML, no pintado con JavaScript. Este es el grande. Muchos rastreadores de IA no ejecutan JS: leen lo que viene en la respuesta y ya. Compruébalo con curl -sL https://tudominio.com/ | grep "una frase de tu página". Si no aparece, para esos modelos tu página está en blanco.
2. No bloquees los rastreadores de IA. Revisa tu robots.txt. Si usas Cloudflare, mira si tienes activado el bloqueo automático de bots de IA: viene encendido en algunas cuentas y decide por ti.
3. Pon un llms.txt en la raíz. Es un archivo de texto que le explica al modelo qué es tu sitio y cuáles son tus páginas importantes. El estándar es joven, cuesta veinte minutos y aún no hay motivo para no tenerlo.
4. Schema de identidad. Es el mismo Person u Organization del paso 5. Para un modelo, ese bloque es la forma más limpia de saber quién eres sin adivinar.

Esto es lo que en las auditorías empieza a aparecer como GEO (Generative Engine Optimization). Es lo bastante nuevo como para que casi nadie lo tenga, y por eso mismo es donde más barato sale destacar hoy.

Pídeselo así:

Comprueba que el contenido principal está en el HTML sin JavaScript en mis páginas
principales, revisa robots.txt para GPTBot, OAI-SearchBot, ClaudeBot, PerplexityBot y
Google-Extended, y redacta un llms.txt con mis páginas importantes. Dime qué tengo que
apagar en Cloudflare.

Lo que hace solo: la comprobación, el robots.txt, el llms.txt y, con token, los dos controles de Cloudflare. Lo que te toca a ti: sin token, apagar el bloqueo de bots de IA en Security y el "Managed robots.txt" en AI Crawl Control. Y decidir si quieres que las IAs te lean. La respuesta suele ser sí.

Los errores que te van a costar tiempo

El skill trae veinticuatro errores documentados en references/errores.md, cada uno con lo que costó. Estos seis son los que más veo:

• Optimizar escritorio y celebrar. Escritorio siempre se ve bien. Tu tráfico es móvil.
• Perseguir el score en vez del negocio. Un 100 que no aparece cuando buscan tu servicio no vale nada. Mide las dos cosas.
• Confiar en el laboratorio. Las herramientas simulan. Abre un navegador real y mide ahí antes de dar algo por bueno.
• Creer que el candado es suficiente. Tener certificado y no forzar HTTPS son cosas distintas. Compruébalo con curl, no mirando la barra del navegador.
• Contar los backlinks sin mirarlos. Cien enlaces de dominios automáticos valen menos que tres de sitios que te mencionan de verdad.
• Cambiar diez cosas a la vez. Si mejora, no sabes cuál fue. Si empeora, tampoco. Un cambio, una medición.

Lo que sí o sí tienes que hacer tú

Con el skill y un token bien acotado, Claude hace la mayor parte del trabajo y lo verifica. Esto no lo puede hacer nadie por ti, y es exactamente donde se atasca casi todo el mundo:

• Cuentas y verificaciones. Search Console, Bing Webmaster Tools, la clave de la API de PageSpeed, tu perfil de empresa en Google. Se verifican con tu DNS o con tu cuenta.
• Pedir indexación en Google. Search Console, Inspección de URLs, "Solicitar indexación", una por una y con cuota diaria. Bing acepta cientos al día, e IndexNow sí se automatiza.
• Interruptores del panel. Forzar HTTPS, HSTS, los dos bloqueos de rastreadores de IA en Cloudflare, la transformación de imágenes. Con un token con el permiso justo Claude los cambia; sin token, los tocas tú.
• Secretos. Tokens y claves los creas tú con el permiso mínimo, los pasas como variable de entorno y los revocas al terminar. Nunca en el chat.
• Los hechos del negocio. Precios, rangos, preguntas reales de clientes, cifras de casos. Claude no puede inventarlos y no debe.
• Aprobar cada texto y cada despliegue. Un cambio, una medición, y el sitio en tu teléfono después.
• Tu teléfono y tu ciudad. Abrir el sitio con datos móviles y buscar tu servicio más tu ciudad en incógnito. Ninguna herramienta ve lo que ves tú desde ahí.
• Perfiles y Wikidata. Editar cada red con tu sesión, crear el ítem con tu cuenta, sugerir cambios en el panel de Google.
• Enlaces. Enviar los mensajes a organizadores, socios y medios. Lo único de la lista que depende de otras personas.
• Ritmo. Publicar. Un sitio en 100 que no publica vuelve a bajar.

Cómo sabes que llegaste

Vuelve a los cuatro números del paso 1 y compáralos. Llegaste cuando:

• Móvil pasa de 85 medido tres veces.
• El salto de contenido está en cero.
• Apareces al buscar tu servicio más tu ciudad, en incógnito.
• Cada servicio que vendes tiene su propia URL indexada.
• Tu dominio obliga HTTPS y no queda ninguna URL sirviendo sin cifrar.
• Los sitios que te enlazan apuntan a la URL buena, y al menos uno lo escribió una persona.

Si te sale todo menos aparecer en la búsqueda, lo que falta suele ser tiempo, entidad (paso 5) y enlaces (paso 7). Son los dos pasos lentos y los que más rinden.