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.

Posicionamiento: que Google te reconozca como entidad

Que Google encuentre tus páginas es una cosa. Que sepa quién eres es otra, y es la que te pone un panel de conocimiento al lado de los resultados y hace que un modelo de IA hable de ti sin inventar. Para Google eres una entidad cuando tu nombre, tu foto, tus empresas y tus perfiles forman un solo nodo, bien conectado, en su grafo de conocimiento.

Esto es lo que hice con chiragx.com, en el orden en que lo volvería a hacer, con lo que funcionó y con lo que me costó caro.

1. Una página que sea tuya: Sobre/Prensa

Todo empieza en tu dominio, porque es lo único que nadie te puede borrar. Mi página Sobre Chiragx tiene una ficha de datos rápidos, una biografía corta, mis perfiles oficiales, mis empresas y una lista de charlas, prensa y medios, cada una enlazada a su fuente. Es mi kit de prensa y la fuente de todo lo demás. Enlázala desde el pie de todas tus páginas.

2. Un solo Person para todo el sitio

En el código, esa página es un ProfilePage cuyo mainEntity es mi Person, con un @id que no cambia: https://chiragx.com/#chiragx. El mismo @id está en el inicio y en mi link in bio, y el sitio y mi servicio lo citan como editor y fundador. Así Google ve una sola persona, no cinco parecidas.

Dos detalles que casi nadie cuida:

• sameAs coherente. La misma lista de perfiles reales, incluido Wikidata, en cada página donde pongas el bloque completo. Si en una página tienes ocho y en otra cinco, le mandas a Google dos versiones de ti. Lo más seguro: el bloque completo en el inicio y en la página Sobre, idéntico, y en el resto solo el @id.
• image como ImageObject. No una URL suelta: un objeto con la URL de tu retrato y un caption con tu nombre. Es la foto que quieres que Google asocie contigo.

{
  "@context": "https://schema.org",
  "@type": "ProfilePage",
  "mainEntity": {
    "@type": "Person",
    "@id": "https://tudominio.com/#persona",
    "name": "Tu nombre público",
    "alternateName": ["Tu nombre legal"],
    "image": {
      "@type": "ImageObject",
      "url": "https://tudominio.com/images/retrato.jpg",
      "caption": "Tu nombre público"
    },
    "sameAs": [
      "https://www.linkedin.com/in/tu-perfil/",
      "https://www.instagram.com/tu-usuario/",
      "https://www.wikidata.org/wiki/Q..."
    ]
  }
}

3. Wikidata, hecho bien

Te van a decir que no crees tu propio ítem porque lo borran por conflicto de interés. A mí me lo dijeron, y lo creí durante meses. En julio de 2026 creé el mío y sigue en pie: Q140753224. Lo que marcó la diferencia:

• Notabilidad con referencias. Wikidata acepta un ítem cuando se puede describir con referencias serias y públicas, o cuando otros ítems lo necesitan. Mis declaraciones clave (ocupación, residencia, la foto) llevan la URL de una fuente externa: agendas de conferencias, notas de prensa, entrevistas. Tu propio sitio no cuenta como prueba.
• Cero tono de venta. Descripción corta y factual. El riesgo de borrado existe: un ítem sin fuentes y con cara de autopromoción termina en la página de solicitudes de borrado.
• Las propiedades que importan. Instancia de: ser humano. Ocupación, residencia, sitio web oficial, el usuario de cada red social y, si tienes una foto con licencia libre en Wikimedia Commons, la imagen.
• Conectado con tus empresas. Cada una de mis empresas tiene su propio ítem, con país, sede, sitio web y la propiedad "fundador" apuntando a mí. Esa conexión es la que convierte un ítem suelto en parte del grafo.
• En las dos direcciones. El ítem apunta a mi sitio y el sameAs de mi sitio apunta al ítem.

Google ya muestra un panel de conocimiento cuando buscas "chiragx", y su subtítulo coincide con la ocupación que declaré en Wikidata. Por eso conviene redactar bien el ítem antes de pedirle nada a Google.

4. Un nombre público que no cambia

Elige el nombre con el que te buscan y no lo toques. El mío es "Chiragx": es único y es lo que la gente escribe. En el schema va en name, y mi nombre legal y sus variantes van en alternateName. En Wikidata es al revés: la etiqueta es mi nombre legal y "Chiragx" va como alias.

Llegué a evaluar unificarlo todo a nombre y apellido para "ordenar" la entidad. Lo descarté: el panel ya salía para "chiragx", y no iba a romper lo que funciona por buscar otra cosa. Las variantes siguen sirviendo como alias.

5. Perfiles que digan lo mismo, letra por letra

LinkedIn, Instagram, YouTube, Facebook y X tienen que coincidir en tres cosas: el nombre, el enlace a tu sitio y los nombres de tus empresas. La biografía puede cambiar de idioma según la red; el nombre no. Si en un perfil dice "Mi Empresa" y en otro "MiEmpresa", para Google son dos empresas distintas. Y si cambias un usuario, actualiza el mismo día tu sameAs, tu llms.txt y Wikidata.

6. Reclama tu panel y usa "Sugerir cambios"

Primero alinea todo lo anterior; después pides. Google contrasta lo que sugieres con lo que encuentra afuera, y si tus perfiles se contradicen, la sugerencia se cae.

• Reclamar. Busca tu nombre, abre el panel y elige reclamarlo. La vía que funciona es entrar con la cuenta de Google que verificó tu dominio en Search Console (o la de tu canal oficial de YouTube). La verificación manual con documentos casi nunca recibe respuesta.
• Sugerir cambios. Ya verificado, sirve para la foto, el nombre y los perfiles. La descripción no se edita ahí: sale de Wikidata.

7. La regla de las fotos (la aprendí con una foto equivocada)

Un día Google puso en mi panel la foto de un socio en un escenario. No fue culpa de Google, fue mía: cada foto de mis galerías de eventos llevaba un alt genérico del tipo "Nombre del evento | Chiragx", saliera yo o no, y el JSON-LD de la galería decía que era sobre mí. Google le creyó a mi sitio.

Lo que hago desde entonces:

• Mi nombre va en el alt, el pie de foto y el schema solo de las fotos donde aparezco. Si hay más gente, digo dónde estoy: "Chiragx a la izquierda, saco gris".
• Si no salgo, describo a quien sale. Si la foto se presta a confusión, agrego "(no es Chiragx)".
• Nada de alts genéricos con la marca al final. "Evento | Marca" en cuarenta fotos le enseña a Google que las cuarenta son tuyas.
• La galería se marca como parte del evento, no de mi persona, y su JSON-LD y su imagen para redes usan solo fotos donde salgo.
• Las carpetas con fotos de otras personas llevan la cabecera X-Robots-Tag: noindex: siguen en el sitio, pero Google Imágenes no las usa.
• Nunca identifico a nadie en una miniatura. Abro la foto a tamaño completo y la comparo con mi retrato.

Una advertencia: al corregirlo, el panel se quedó sin foto. Google no agrega una a pedido; tiene que volver sola. Cuando vuelva, el dueño verificado del panel puede proponer otra pegando la URL directa de la imagen.

8. Deja entrar a las IAs: robots.txt y llms.txt

Cada vez más gente le pregunta a un modelo en vez de buscar en Google. Yo quiero que me citen, así que mi robots.txt permite todo y además nombra a los bots de IA uno por uno:

User-agent: *
Allow: /

User-agent: GPTBot
Allow: /

User-agent: OAI-SearchBot
Allow: /

User-agent: ClaudeBot
Allow: /

User-agent: PerplexityBot
Allow: /

User-agent: Google-Extended
Allow: /

Sitemap: https://tudominio.com/sitemap.xml

Dos trampas. La primera: un bot con grupo propio ignora el grupo general, así que si ahí bloqueas algo (por ejemplo, tu panel de administración), repítelo en cada grupo. La segunda, si usas Cloudflare: el archivo que se sirve puede no ser el tuyo. La opción "Managed robots.txt" de AI Crawl Control me inyectaba un bloque que frenaba a los bots de entrenamiento y contradecía mi propio archivo. La apagué y desbloqueé todos los crawlers. Compruébalo con curl https://tudominio.com/robots.txt: si aparece un bloque que no escribiste, se volvió a encender.

Y publica un llms.txt en la raíz: un resumen en Markdown de quién eres, qué haces, tus páginas clave, tus perfiles y tu ítem de Wikidata. Es una propuesta, no un estándar, y no esperes que mueva Google; pero toma diez minutos y algunos asistentes lo leen. En mi caso, los datos de Cloudflare ya mostraban a OpenAI y a Apple recuperando mis artículos.

9. Pide la indexación, y ten paciencia

Nada de esto cuenta hasta que Google vuelve a pasar. Después de cada cambio de schema, de alts o de fotos, entra a Search Console, inspecciona la URL y pide la indexación, empezando por el inicio y la página Sobre. Para sacar rápido una imagen de los resultados, usa Retiradas. Y declara en tu sitemap las fotos donde sí sales, para que Google tenga con qué reemplazar la equivocada.

Si el título que muestra Google no coincide con el de tu código, no lo edites otra vez: Google todavía no volvió a rastrear. El panel no se pide, se gana. Puedes hacerlo todo bien y esperar semanas o meses. Lo que sí controlas es que, cuando Google mire, todo diga lo mismo.

Pídeselo así:

Usa el skill web-playbook-100, references/entidad.md. Mi sitio es https://midominio.com. Revisa mi página Sobre y el JSON-LD Person de todas mis plantillas: un solo @id, la misma lista de sameAs donde va el bloque completo e image como ImageObject. Revisa los alt de mis galerías con la regla de las fotos y dime cuáles corregir. Comprueba mi robots.txt y mi llms.txt. Busca fuentes independientes sobre mí y dime si califico para Wikidata, con qué referencias y qué propiedades. No cambies nada hasta que yo apruebe.

Lo que hace solo: el schema, la revisión de los alt, el robots.txt, el llms.txt y el borrador del ítem de Wikidata con sus fuentes. Lo que te toca a ti: crear el ítem con tu cuenta y responder si lo cuestionan, alinear tus perfiles con tu sesión, reclamar el panel con la cuenta dueña de tu dominio y pedir la indexación en Search Console.

Preguntas frecuentes

¿Qué métricas SEO tengo que mirar para mejorar?

Pocas y siempre las mismas. En Search Console: clics, impresiones, CTR y posición media, por consulta y por página. En PageSpeed, en móvil y con la mediana de tres corridas: LCP, CLS e INP. Y la prueba que no miente: buscar tu servicio más tu ciudad en incógnito. Si una métrica no te dice qué arreglar, no la mires todos los días.

¿Se puede mejorar el posicionamiento sin backlinks?

Hasta un punto, sí. Lo técnico, el rendimiento, una página por servicio y la entidad te pueden llevar de no aparecer a salir por tu nombre y por tu servicio en tu ciudad. Para búsquedas con competencia, los enlaces que escribió una persona siguen pesando. Los más fáciles son tus propias propiedades y los sitios donde ya apareciste (paso 7).

¿Cuánto tarda en notarse?

Lo técnico y el rendimiento se ven en PageSpeed el mismo día. En Google, los títulos nuevos y las páginas nuevas suelen notarse en días o semanas, según cada cuánto rastrea tu sitio. La entidad y los enlaces son lo más lento: cuenta meses, no días.

¿Qué es el crawl budget y me afecta?

Es cuántas páginas de tu sitio rastrea Google en un tiempo dado. En un sitio de decenas o cientos de páginas casi nunca es el problema. Lo que sí ayuda es un sitemap limpio, sin redirecciones ni URLs duplicadas, y que cada página responda 200 con su canonical.

¿Necesito saber programar para hacer esto?

No. El skill hace casi todo con Claude Code. Lo que te toca a ti son las cuentas, las claves y aprobar cada cambio antes de publicarlo.