Blog propio + preview cards en la web (prioridad SEO/GEO)

[02KellyDev]

No tenemos blog y tenemos muchas historias que contar para cada edicion de caribeconf. Se evaluó publicar todo en Medium.com o dev.to y luego mostrar ese contenido en la web de la conferencia (como preview cards o como un "lector" dinámico), priorizando siempre nuestro propio índice de SEO y GEO (motores generativos tipo ChatGPT/Perplexity/Google AI Overviews).

Recomendación (dos capas)

1. Fuente de verdad en dominio propio. El crédito de SEO y las citas de motores de IA se acumulan sobre el dominio donde vive el contenido primero, no sobre el de terceros. Dos caminos válidos:

• Hashnode con dominio propio (blog.caribeconf.com): gratis, SSL automático vía Let's Encrypt, editor en Markdown, y modo headless por API GraphQL si más adelante se quiere un frontend propio. Rápido de montar y suma algo de audiencia propia de Hashnode.
• Blog nativo en el monorepo: Astro trae content collections/MDX de fábrica, todo viviría en caribeconf.com/blog. Cero dependencias externas, pero cada post implica un PR — más control, más fricción para publicar rápido.

2. Redifusión opcional a Medium/dev.to, solo si se quiere alcance extra en esas comunidades, completando siempre el campo canonical_url (dev.to tiene API REST: POST https://dev.to/api/articles) o el equivalente en Medium ("Import a story"), apuntando de vuelta al post original. dev.to permite automatizar esto con una GitHub Action al publicar.

• Nota real: aunque el canonical esté bien puesto, si dev.to indexa el artículo antes que nuestro propio dominio, Google a veces igual muestra la copia de dev.to primero. Mitigación: publicar primero en el dominio propio, mandarlo a indexar en Google Search Console, y esperar 24–48h antes de redifundir.

3. En caribeconf.com y 2025.caribeconf.com: preview cards, no un "lector" que reconstruya el contenido ajeno. Reconstruir la página de otro sitio duplica contenido (malo para SEO), es frágil (depende de que no cambien su HTML) y puede chocar con sus términos de uso. En cambio, consumir la metadata pública vía API/RSS oficial (API de dev.to, feed RSS de Hashnode o Medium) — título, imagen, extracto, fecha — y mostrar tarjetas que enlacen ("Leer completo →") al post real.

Checklist SEO/GEO a incluir

• JSON-LD tipo BlogPosting/Article en cada post
• llms.txt en la raíz de caribeconf.com listando agenda, speakers, fotos y blog (convención emergente, aún no confirmada por los motores grandes, pero de costo casi cero)
• Confirmar que robots.txt no bloquea crawlers de IA (GPTBot, ClaudeBot, PerplexityBot) además de Googlebot
• rel="canonical" correcto en cada copia redifundida
• RSS/sitemap del blog descubribles y enviados a Search Console
• Un H1 único por post, y primer párrafo que responda la idea central directamente (los motores generativos citan mejor los bloques con la respuesta arriba)

Tareas de implementación

• Decidir plataforma fuente (Hashnode con dominio propio vs. blog nativo en Astro)
• Configurar blog.caribeconf.com si aplica (CNAME + verificación)
• Escribir los primeros 2–3 posts (los recaps de 2025 y 2026 son buen punto de partida — conecta directo con el Issue 1 de fotos)
• Construir <BlogPreviewCards /> en packages/shared que consuma el feed (API/RSS) y muestre 3–6 tarjetas en la home
• (Si aplica) automatizar redifusión a dev.to vía GitHub Action + canonical_url
• Agregar JSON-LD, llms.txt y revisar robots.txt

Criterios de aceptación

• Existe un lugar canónico (dominio propio) donde vive el contenido completo
• La home muestra preview cards de los últimos posts, cada una enlazando al post real
• Ningún contenido de terceros se reconstruye o scrapea dentro de nuestro dominio