Un descubrimiento incómodo sobre mi propio blog
Publicar contenido nuevo es visible y satisfactorio: se nota, se puede compartir, da la sensación de avance. Revisar el sitemap de tu propio blog es aburrido y, la mayoría de las veces, no encuentras nada. Por eso es tan fácil posponerlo indefinidamente.
Hice esa revisión en caprini.dev y encontré algo que no esperaba: había artículos publicados en Ghost, presentes en el sitemap generado automáticamente, que sin embargo no aparecían en el listado visual del índice de artículos del propio sitio. Estaban publicados, tenían URL pública funcionando, pero una persona navegando desde la página principal del blog nunca llegaría a ellos, porque el listado que ve no los incluía.
Por qué esto es más grave de lo que parece a simple vista
Un artículo con este problema está en una situación extraña: no está oculto (tiene URL pública, aparece en el sitemap, un buscador puede indexarlo si lo rastrea), pero tampoco está completamente visible (nadie que navegue el blog de forma normal lo va a encontrar por sí solo, porque el propio índice del sitio lo omite).
Esto significa que todo el esfuerzo de escribir ese artículo puede quedar parcialmente desperdiciado: existe, pero solo lo va a encontrar quien llegue directamente por un enlace externo o por una búsqueda muy específica, nunca alguien que simplemente explore el blog.
La causa técnica probable
En mi caso, el blog usa Ghost como backend de contenido y un frontend en Next.js que consume ese contenido mediante la Content API, como explico en Ghost headless con Next.js. El sitemap se genera a partir de la lista completa de contenido publicado, sin filtros adicionales. El índice visual de artículos, en cambio, pasa por lógica adicional del frontend que probablemente aplica algún filtro (por tag, por tipo de contenido, o por el momento de la última regeneración de la página) que no está capturando absolutamente todo lo publicado.
No he corregido este filtro del frontend en el momento de escribir esto, porque quiero entender bien la causa exacta antes de tocar el código de producción sin necesidad. Pero el hallazgo en sí ya cambia cómo reviso mi propio blog.
Por qué reviso el sitemap antes de escribir el siguiente artículo
Este descubrimiento me hizo reordenar prioridades. Antes de escribir un artículo número veintiuno, prefiero confirmar que los veinte anteriores están realmente accesibles desde donde deberían estarlo. No tiene sentido acumular contenido nuevo si una parte del contenido existente es efectivamente invisible para quien navega el sitio de forma normal.
Mi checklist ahora incluye:
- Comparar el número de URLs de artículos en el sitemap con el número de artículos que aparecen en el índice visual del blog.
- Si hay discrepancia, identificar exactamente qué artículos faltan y por qué (tag, categoría, fecha, tipo de contenido).
- Verificar manualmente, entrando directamente a la URL de cada artículo "perdido", que el contenido en sí sigue siendo correcto y no ha quedado desactualizado por el mismo problema de sincronización.
- Documentar el hallazgo antes de decidir si la corrección es un cambio de filtro en el frontend o un ajuste en cómo se etiqueta el contenido en Ghost.
Lo que este caso no significa
Quiero ser preciso sobre el alcance de esta observación: no significa que el sitemap sea garantía de indexación en buscadores (eso depende también de rastreo, calidad percibida y otros factores que no controlo directamente), ni que todos los blogs headless tengan este problema. Es una observación factual sobre mi propio sitio, no una afirmación general sobre Ghost, sobre Next.js, ni sobre arquitecturas headless en conjunto.
Tampoco significa que deba dejar de publicar contenido nuevo. Significa que la publicación y la verificación de que lo publicado es accesible son dos tareas distintas, y que solo hacer la primera no es suficiente.
Qué haría distinto si empezara de nuevo
Si tuviera que montar de nuevo la infraestructura de contenido de caprini.dev, incluiría desde el primer día una comprobación automática que compare periódicamente el número de posts publicados en Ghost con el número de artículos que muestra el índice del frontend, y que avise si hay una diferencia. No hace falta que sea sofisticada: un script sencillo que consulte ambas fuentes y compare los totales sería suficiente para detectar este tipo de desincronización mucho antes de descubrirla por casualidad, como me ocurrió a mí.
Es una lección que aplico ahora hacia adelante: cualquier pieza de la infraestructura que dependa de dos fuentes distintas de la misma información merece, desde el principio, una forma de comprobar que ambas siguen diciendo lo mismo.
Cómo se relaciona con el resto de mi criterio de SEO
Esta comprobación de sitemap encaja con lo que ya trato en SEO técnico básico para un blog pequeño: la indexación no se puede asumir, se verifica. Y encaja también con cómo pienso los enlaces internos en un blog técnico, porque un enlace interno hacia un artículo que el propio índice del sitio no muestra sigue siendo la única forma de que alguien navegando el blog llegue hasta él.
Referencia oficial sobre sitemaps: Información general sobre sitemaps de Google Search Central.
Conclusión
Veinte artículos nuevos no compensan uno que ya existe pero que nadie puede encontrar navegando el sitio con normalidad. Revisar el sitemap y compararlo con lo que realmente se muestra en el blog es una tarea aburrida, sin la satisfacción inmediata de publicar algo nuevo, pero es probablemente la revisión con mejor relación entre tiempo invertido y contenido recuperado que puedo hacer en este momento.
