Auditamos nuestro propio sitio. Esto es lo que encontramos y arreglamos.
El problema del zapatero descalzo
Vendemos optimizacion AEO. Creamos archivos llms.txt para nuestros clientes. Implementamos schema markup en cada sitio que entregamos. Y cuando corrimos una auditoria SEO completa en commerceking.ai, encontramos 27 problemas en nuestro propio sitio.
No teniamos un archivo llms.txt. Nuestro schema de Organization apuntaba a un logo que no existia. La pagina principal en espanol estaba renderizando datos de FAQ en ingles dentro del markup estructurado. El subdominio www servia una copia completa del sitio en lugar de redirigir.
Todas las agencias tienen este problema. Te pasas todo el tiempo construyendo para clientes y tu propio sitio queda abandonado. Decidimos arreglar esto de forma publica porque la transparencia es parte de como operamos.
Lo que encontro la auditoria
Corrimos siete auditorias en paralelo: SEO tecnico, calidad de contenido, schema markup, validacion de sitemap, rendimiento, visual/movil y preparacion para busqueda IA (GEO). El puntaje general salio en 68 de 100. No esta mal, pero no es donde deberia estar una agencia que vende AEO.
Los problemas criticos
Sin archivo llms.txt. Este es el archivo que le dice a los rastreadores de IA (ChatGPT, Claude, Perplexity) quien eres y que haces. Literalmente vendemos esto como servicio. No tenerlo en nuestro propio sitio fue el hallazgo mas vergonzoso de la auditoria.
La referencia de imagen Open Graph estaba rota. Cada pagina apuntaba a social-card.png, pero el archivo real se llamaba opengraph.jpg. Cada vez que alguien compartia el sitio en redes sociales, la preview salia rota.
La pagina principal en espanol tenia contenido de FAQ en ingles en sus datos estructurados. Tenemos un sitio bilingue (ingles y espanol) y el schema estaba jalando del archivo de datos equivocado.
Los problemas tecnicos
Cero headers de seguridad. Sin HSTS, sin Content-Security-Policy, sin X-Content-Type-Options. Agregamos los seis headers recomendados a traves de una configuracion customHeaders.yml en Amplify.
El subdominio www estaba sirviendo el sitio completo con HTTP 200 en lugar de redirigir al dominio canonico sin www. Lo arreglamos con un solo comando de AWS CLI para agregar una regla de redireccion 301 en Amplify.
Las etiquetas hreflang tenian inconsistencias con la barra diagonal final. El hreflang para el sitio en espanol apuntaba a /es (sin barra) mientras que la URL canonica era /es/ (con barra). Google los trata como URLs diferentes.
Google Fonts se cargaba como una solicitud cross-origin que bloqueaba el renderizado, sin hint de preconnect. Agregamos preconnect para Google Fonts, gstatic y HubSpot, y eliminamos un peso de fuente que no se usaba.
Los problemas de contenido
Dos paginas tenian contenido criticamente delgado. El indice de servicios tenia 120 palabras (una cuadricula de tarjetas sin contexto). La pagina del servicio de ecommerce tenia 250 palabras (una lista de plataformas sin explicacion de como elegimos plataformas o como hacemos migraciones). Las expandimos a 500+ y 900+ palabras respectivamente.
El dato del hero decia "10+ anos en comercio" mientras que la pagina de nosotros decia "16+ anos." Elegimos el numero correcto y lo hicimos consistente en todo el sitio.
Lo que construimos
llms.txt
Creamos un archivo llms.txt estructurado en commerceking.ai/llms.txt que describe quienes somos, que hacemos, las credenciales de nuestro equipo, las plataformas con las que trabajamos y nuestro ecosistema de marcas. Cualquier sistema de IA que rastree nuestro sitio ahora tiene un resumen limpio y estructurado con el que trabajar.
Gestion de rastreadores de IA
Actualizamos robots.txt con reglas explicitas para rastreadores de IA. Los rastreadores orientados a busqueda (GPTBot, ClaudeBot, PerplexityBot) estan explicitamente permitidos. Los rastreadores solo de entrenamiento (CCBot, Google-Extended) estan bloqueados. Esto nos da control sobre como los modelos de IA consumen nuestro contenido sin bloquear los sistemas que nos citan en resultados de busqueda.
Schema markup en cada pagina
Agregamos datos estructurados a nueve paginas que no tenian ninguno. Schema de AboutPage con markup de Person para los cuatro miembros del equipo. Schema de ContactPage. Schema de Service y BreadcrumbList en siete paginas de servicios. Las publicaciones del blog ahora generan schema de Article con datos de autor, fecha y editor.
Sistema de formularios bilingue
Reemplazamos un placeholder de "proximamente" en la pagina de contacto con un formulario real de HubSpot. El sitio en ingles tiene el formulario en ingles. El sitio en espanol tiene un formulario separado en espanol. El boton de envio esta en nuestro naranja de CTA.
Mejoras de rendimiento
Hints de preconnect para tres dominios externos. Eliminamos un peso de fuente que no se usaba. Las imagenes hero del blog ahora tienen fetchpriority="high" y dimensiones explicitas para prevenir CLS. El sitio ya tenia buenas puntuaciones en Core Web Vitals (sitio estatico Astro con texto primero), pero estos cambios ajustan los margenes.
El resultado
Arreglamos 27 problemas en dos dias de trabajo enfocado. El sitio ahora tiene un archivo llms.txt, reglas explicitas para rastreadores de IA, schema markup en cada pagina, headers de seguridad, una redireccion www correcta, formularios bilingues de HubSpot y contenido expandido en las dos paginas mas delgadas.
Nada de esto requirio un rediseno. Nada cambio la apariencia visual del sitio. Estas son las mejoras de infraestructura invisible que determinan si los sistemas de IA pueden encontrarte, entenderte y citarte en resultados de busqueda.
Este es el mismo proceso que corremos para cada cliente. La diferencia es que lo hicimos en nuestro propio sitio y lo escribimos para que puedas ver exactamente como se ve el trabajo.
Lo que falta por hacer
Casos de estudio con ejemplos reales de proyectos. Testimonios de clientes. Fuentes auto-hospedadas en lugar de Google Fonts. Imagenes Open Graph especificas por pagina en lugar de una sola compartida. Estan en el plan. Tambien escribiremos sobre eso cuando se lancen.