Una web no termina cuando la publicas. Entonces empieza el trabajo de barro

Hay una idea que se repite mucho: hoy una web se hace en cinco minutos. Eliges una plantilla, escribes cuatro textos, conectas un dominio y ya está. Y sí, puedes conseguir que una página exista en cinco minutos. Otra cosa muy distinta es conseguir que funcione como un sistema.

Mi web no es un adorno. Es mi escaparate personal, el lugar donde cuento lo que construyo, documento casos reales y dejo rastro de mi trabajo. El diseño y los contenidos ya habían pasado su propia revisión. Esta semana tocaba mirar lo que queda debajo: qué puede rastrear un buscador, cómo entiende cada página, qué relaciones existen entre los contenidos y qué ocurre de verdad cuando todo se publica.

Tres capas distintas que tenían que encajar

No hicimos tres auditorías aisladas ni utilizamos las siglas como etiquetas. Revisamos cómo se apoyan entre sí dentro de la misma web:

Una capa no sustituye a las otras. Una página puede ser rastreable y ofrecer una respuesta confusa. Puede tener buen contenido y atribuirlo a una entidad incoherente. O puede describir perfectamente a su autora y seguir enterrada a cuatro clics de la portada. Por eso auditamos el conjunto.

La auditoría empezó el 21 de octubre y cerró su parte técnica el 25. No consistió en pulsar un botón y copiar una puntuación. Consistió en revisar el repositorio, proteger cambios que pertenecían a otros trabajos, comparar páginas, corregir lotes pequeños, validar cada bloque y comprobar el mismo proceso que utiliza producción.

El primer problema no era SEO. Era de control. En el repositorio convivían cambios recientes, trabajo todavía no publicado y archivos recuperados que no correspondían al sistema actual. La regla fue sencilla: no mezclar tareas, no borrar por intuición y no publicar nada que no estuviera revisado.

También aparecieron problemas de Git que no tenían nada que ver con el contenido: una referencia remota dañada y commits nuevos en el servidor que no estaban en local. Resolver eso formó parte del trabajo. Una auditoría no sirve si, al intentar publicarla, el historial se pisa o el despliegue se construye desde un estado distinto al que has revisado.

Partimos del sitemap y construimos un inventario verificable. Al cerrar la revisión había 98 URLs públicas. Todas respondían con código 200 y todas se podían alcanzar desde la arquitectura interna del sitio.

Esto permitió dejar de hablar con impresiones. Una página podía verse bien y tener una canonical equivocada. Otra podía tener una imagen social que no existía. Un artículo podía estar enlazado únicamente desde el índice general. Y un aviso podía parecer grave hasta comprobar que no afectaba a la página que Google debía indexar.

El fichero de verificación de Google, por ejemplo, se mantuvo porque cumple una función concreta: demostrar la propiedad del dominio. Está disponible, pero no forma parte del sitemap ni es contenido editorial. El objetivo no era borrar todo lo que no pareciera una página; era entender para qué sirve cada archivo.

Para no dar vueltas sobre lo mismo, cada hallazgo recibió un identificador, una prueba y una decisión. Esa parte de la documentación fue tan importante como el cambio en sí: permitió saber por qué un archivo se quedaba, por qué otro se retiraba y qué aviso no justificaba tocar setenta páginas de golpe.

Este cuadro resume algo que las auditorías automáticas no pueden decidir: una alerta no contiene por sí sola la solución. Hay que entender el sistema antes de tocarlo.

Las 98 páginas terminaron con título, metadescripción, canonical propio, un único H1, idioma español, viewport, indexación permitida e imagen Open Graph local accesible. También comprobamos 109 destinos internos de página y 161 recursos internos únicos: no quedó ninguno roto ni pasando por una redirección.

Dieciséis portadas que no estaban resolviendo su trabajo

Diez artículos no declaraban una imagen social propia y seis apuntaban a un archivo que devolvía 404. No las sustituimos con cualquier fotografía. Primero aprobamos una prueba piloto y, a partir de ella, construimos un sistema claro de 1200 × 630 píxeles con el logotipo original, tipografías Inter y JetBrains Mono, fondo claro, negro y ámbar. Todas quedaron en JPEG progresivo, sRGB y por debajo de 200 KB.

Se hicieron en tres lotes de cinco y un último artículo legal. En ese último caso respetamos su fecha histórica: una página publicada en una fecha concreta no está “desactualizada” solo porque la revisemos hoy. La fecha editorial y una corrección técnica son cosas distintas.

Cuarenta dimensiones y diecinueve imágenes antiguas

Siete páginas contenían cuarenta imágenes sin ancho y alto explícitos en el HTML. Añadimos sus dimensiones intrínsecas reales, una por una, sin cambiar el tamaño visual ni romper el comportamiento adaptable. Eso ayuda al navegador a reservar espacio antes de cargar la imagen y reduce el riesgo de saltos de contenido.

Después cruzamos 236 imágenes rastreadas con 135 archivos de texto, duplicados binarios e historial. Retiramos diecinueve recursos recuperables: nueve PNG antiguos sustituidos por JPG activos, cinco copias idénticas, una copia de la imagen principal y cuatro archivos obsoletos. También desaparecieron quince exclusiones muertas del proceso de construcción. El inventario terminó con 217 imágenes rastreadas y ninguna sin referencia. Conservamos seis pares duplicados porque pertenecen a un paquete de firma de correo autosuficiente.

Lo que decidimos no “optimizar”

Los 69 títulos de más de 60 caracteres y las 39 descripciones de más de 160 quedaron anotados, no recortados en masa. Esas longitudes pueden influir en cómo se muestra un resultado, pero no son un límite absoluto de indexación. Sin consultas, CTR y fragmentos reales de Search Console, cambiar setenta páginas habría sido sustituir evidencia por una plantilla.

También revisamos la caché. robots.txt tenía 24 horas, el sitemap una hora, llms.txt 24 horas y la carpeta de imágenes 30 días. Algunos recursos de raíz usaban revalidación. Podíamos alargarla, sí, pero sin nombres versionados una imagen actualizada podría seguir mostrándose vieja. Como ETag y 304 funcionaban, no tocamos esa parte.

El inventario inicial encontró 85 bloques FAQPage con 443 preguntas. Una comparación literal señaló 269 diferencias repartidas en 63 páginas. Esa cifra impresionaba, pero no significaba que hubiera 269 errores: una respuesta puede estar escrita con otras palabras y seguir siendo equivalente. La máquina podía filtrar candidatos; no podía cerrar el diagnóstico.

Empezamos con tres casos muy diferentes. En el artículo sobre automatizar el teléfono había tres respuestas ocultas que añadían porcentajes y funciones no desarrolladas de forma visible. Retiramos solo ese bloque FAQ. En la guía de modelos de ChatGPT aparecieron dos diferencias literales, pero al leerla comprobamos que las ocho respuestas sí estaban visibles y decían lo mismo: no se cambió nada. En el artículo sanitario, siete preguntas no existían como FAQ visible y podían introducir afirmaciones delicadas, así que también retiramos únicamente el marcado.

Con el piloto aprobado, revisamos las 63 páginas por lotes de cinco y después de diez. No añadimos texto visible para justificar el schema y no reescribimos el artículo para salvar una FAQ. Cuando el marcado no representaba el contenido, se retiraba el marcado. Al terminar la fase editorial quedaron 16 FAQPage válidos en artículos; el cierre de todo el sitio contabilizó 27 al incluir páginas comerciales y sectoriales.

Esto coincide con las políticas generales de datos estructurados de Google: el marcado debe representar el contenido visible y correcto. Además, Google redujo la presencia de FAQ enriquecidas en 2023 y deprecó ese resultado enriquecido en 2026. Mantener centenares de respuestas ocultas para perseguir un resultado visual que ya no existe no tenía sentido.

También quedaron 78 páginas con SpeakableSpecification y 295 selectores válidos. No lo retiramos automáticamente porque era técnicamente coherente. Pero tampoco lo presentamos como una gran ventaja: la documentación oficial de Speakable sigue describiendo una función beta, orientada a noticias en inglés y dispositivos Google Home en Estados Unidos.

Para mí, AEO aquí no significó añadir más preguntas. Significó conseguir que cada respuesta marcada pudiera defenderse delante de una persona.

El inventario encontró el nodo de organización #organization 98 veces y el de persona #mili 101 veces. Sin embargo, Mugen AI aparecía 74 veces como “Mugen AI S.L.U.” y 24 como “Mugen AI”; solo 23 casos separaban correctamente nombre comercial y razón social. La URL de la organización variaba con y sin barra final, diez nodos utilizaban el LinkedIn personal de Mili como si fuera un perfil corporativo y la URL personal alternaba entre la portada, la página Tech o directamente faltaba.

Definimos un contrato único: Mili Pérez como persona con el identificador #mili, URL /tech.html, perfiles personales cuando correspondía y relación worksFor; Mugen AI como organización con #organization, nombre comercial “Mugen AI”, razón social “Mugen AI S.L.U.”, URL canónica con barra final y relación de fundadora hacia Mili. No inventamos un perfil corporativo para completar sameAs: si no estaba confirmado, se omitía.

La aplicación fue deliberadamente gradual: seis páginas principales, siete lotes de diez artículos, dos artículos estándar, cuatro páginas con JSON-LD minificado y, después de un inventario global, otras diecisiete páginas no editoriales. En estas últimas entraron diez páginas comerciales y sectoriales y un último lote de siete. Preservamos descripciones contextuales, cargos, temas conocidos y entidades específicas de cada sector.

La documentación de Article de Google recomienda identificar al autor y enlazarlo con una página que permita entender quién es. Ese fue el sentido del cambio: no prometer una cita de una IA, sino eliminar contradicciones sobre autoría y publicación.

Los rastreadores de IA tampoco son todos lo mismo

robots.txt permitía OAI-SearchBot y GPTBot. Los mantuvimos, pero documentamos que no cumplen la misma función. Según la documentación oficial de OpenAI, OAI-SearchBot se usa para funciones de búsqueda y GPTBot para posibles usos de entrenamiento; permitir uno no obliga a permitir el otro. Esa política queda como una decisión consciente del sitio, no como un truco de posicionamiento.

llms.txt terminó incluyendo todas las URLs del sitemap más las páginas legal y de privacidad. Sirve como inventario legible, pero no lo tratamos como un factor de Google: las actualizaciones oficiales de Google aclaran que no es necesario para Google Search y que no mejora ni empeora la visibilidad por sí mismo.

Al principio había 24 artículos accesibles únicamente desde el índice editorial. No eran huérfanos, pero tenían poco contexto. Los leímos uno por uno y añadimos 19 enlaces desde frases que ya existían. No escribimos párrafos de relleno, no añadimos bloques de “también te puede interesar” por sistema y no forzamos anclas extrañas.

Cinco artículos quedaron enlazados solo desde el índice porque no encontramos una relación editorial suficientemente natural: HyperFrames, una feria comercial en China, precontabilidad, la pieza de SEO/AEO/GEO y la API Cloud de netelip. Dejarlos así fue una decisión, no un olvido.

La guía de ChatGPT para equipos sí merecía una ruta más corta. Estaba a cuatro clics desde la portada y pasó a tres mediante un único enlace exacto desde la guía de modelos de ChatGPT. No reactivamos un índice antiguo de recursos ni cambiamos el menú global para resolver una sola URL.

También corregimos el único enlace interno que pasaba por una redirección: un artículo sobre ponis apuntaba a la versión antigua de /agentes-de-voz-ia.html y pasó a enlazar directamente con /agentes-de-voz-ia.

El grafo final tenía las 98 páginas alcanzables y una profundidad máxima de tres. Es una mejora pequeña de explicar y lenta de hacer bien: leer, decidir si dos piezas se ayudan de verdad, editar el enlace y volver a comprobar que no se ha roto nada.

La API de PageSpeed respondió primero con un 429 por límite de cuota. En lugar de completar la tabla con números inventados, utilizamos informes públicos de PageSpeed Insights. La muestra se ejecutó con Lighthouse 13.5, emulación de Moto G Power y una red 4G lenta.

Las cuatro páginas terminaron con TBT de 0 y CLS entre 0 y 0,018. En las tres primeras aparecía una oportunidad de reducir solicitudes que bloqueaban el renderizado, con una estimación cercana a 1,9 segundos. La calculadora y el índice tenían además avisos de contraste, que son asuntos de accesibilidad y diseño, no una explicación automática de indexación.

La guía obtuvo dos de tres puntos en una prueba experimental de navegación para agentes. Tampoco convertimos eso en un fallo GEO. Una métrica experimental puede orientar una futura prueba; no demuestra que Google o un asistente no comprendan la página.

Trabajamos con una división muy concreta: yo revisaba cada lote y preparaba un commit aislado; Mili hacía el push. Eso nos permitía comprobar qué se iba a publicar antes de enviarlo y evitaba mezclar la auditoría con cambios simultáneos de la calculadora, el manifiesto, recursos o artículos nuevos.

En mitad del proceso Git empezó a devolver fatal: bad object refs/remotes/origin/HEAD 2. No era un fallo del artículo: iCloud había restaurado dentro del repositorio una referencia duplicada. Después aparecieron commits más nuevos en el remoto y hubo que traerlos antes de continuar, sin pisar el trabajo local.

Desactivamos iCloud Drive para esa carpeta, conservamos una copia archivada y dejamos solo el repositorio activo en el Escritorio. Cuando una restauración antigua reapareció dentro del proyecto, se sacó fuera sin enviarla a la papelera. Nada se borró por impulso y nada antiguo terminó publicado por accidente.

El sitio genera el índice de artículos, el sitemap, las redirecciones y llms.txt durante la publicación. Por eso repetimos el proceso completo de Netlify en una copia temporal limpia. El cierre original encontró 76 artículos, creó 98 entradas de sitemap, preparó 98 redirecciones canónicas y construyó 391 archivos públicos.

El validador terminó con 0 errores y 0 avisos. Las 98 URLs del sitemap devolvieron 200. Las 98 redirecciones generadas y las seis reglas históricas adicionales devolvieron 301 y llegaron a su destino previsto. Los 200 bloques JSON-LD se pudieron interpretar. No quedó ninguna URL huérfana.

Comparamos además archivos locales con producción. La portada, la calculadora, el índice editorial, el artículo de ChatGPT, la guía para equipos, el artículo de los ponis y robots.txt coincidían byte a byte. El sitemap público y llms.txt coincidían semánticamente con la construcción limpia; la única diferencia era la marca temporal automática.

Search Console quedó apartado de forma deliberada. Los CSV disponibles eran del 12 de octubre y no representaban con precisión los cambios publicados después. Con esos datos antiguos no íbamos a explicar exclusiones actuales, solicitar indexación en masa ni cambiar títulos y descripciones sin saber qué consultas generaban impresiones.

Por tanto, esta auditoría no demuestra un aumento de tráfico, clics, impresiones, CTR ni posiciones. Tampoco certifica que Google haya incluido ya las 98 URLs en su índice, ni aporta Core Web Vitals de campo, estado actualizado de acciones manuales o seguridad. Todo eso exige una lectura nueva dentro de Google Search Console.

Cuando retomemos esa fase, revisaremos cobertura y motivos URL por URL, rendimiento de tres y dieciséis meses, consultas, páginas, países, dispositivos, Core Web Vitals, HTTPS, sitemaps, acciones manuales y problemas de seguridad. Después compararemos ese estado con la exportación histórica del 12 de octubre.

La diferencia importa. La auditoría técnica reduce fallos y contradicciones; el buscador decide cuándo rastrea, qué indexa y cómo lo presenta. Esa parte no se promete. Se mide.

¿Una web está terminada cuando se publica?

No. Publicarla deja disponible el diseño y el contenido, pero después hay que comprobar rastreo, indexabilidad, metadatos, enlaces, redirecciones, datos estructurados, rendimiento y el funcionamiento del despliegue.

¿Qué se revisó en esta auditoría de miliperez.com?

Se revisaron 98 URLs del sitemap, sus respuestas, metadatos, canonicales, encabezados, imágenes sociales, datos estructurados, FAQ, identidad de personas y organización, enlazado interno, redirecciones y el resultado del proceso de publicación.

¿Se corrigió automáticamente todo lo que señaló una herramienta?

No. Los avisos se usaron como pistas y cada cambio se contrastó con el contenido visible, la intención de la página y el sistema de publicación. Una diferencia detectada por una herramienta no siempre es un error real.

¿Los datos estructurados garantizan aparecer en Google o en una IA?

No. Ayudan a describir el contenido y sus entidades de forma legible para máquinas, pero no garantizan indexación, posiciones, respuestas enriquecidas ni menciones en sistemas de inteligencia artificial.

¿Qué queda después de cerrar la auditoría técnica?

Queda el mantenimiento: vigilar Search Console, medir rendimiento, revisar nuevos contenidos, comprobar enlaces y despliegues, y volver a auditar cuando el sitio cambie. La parte técnica puede cerrarse; la web sigue viva.