¿Puedes usar Notion como backend de un sitio web?
Has visto las demos: alguien construye un sitio de portafolio completamente impulsado por Notion, lo despliega en Vercel y afirma que no tiene costos de suscripción. El atractivo es obvio: tu cliente actualiza el contenido en una herramienta que ya conoce, y tú te saltas completamente la sobrecarga de WordPress.
Pero ¿realmente puedes usar Notion como backend para sitios web en producción? La respuesta es sí, con advertencias importantes. Este artículo desglosa la arquitectura, las compensaciones reales de ingeniería, y cuándo tiene sentido este enfoque versus cuándo se desmorona.
Puntos clave
- Notion puede servir como un CMS headless ligero al combinar su API con un frontend personalizado construido en frameworks como Next.js o Astro.
- Este enfoque funciona mejor para sitios de contenido pequeños, portafolios, prototipos y MVPs donde la experiencia de edición importa más que la escala.
- Los límites estrictos de la API, las URLs de archivos que expiran, el soporte incompleto de tipos de bloques y los webhooks de solo señalización imponen restricciones reales de ingeniería.
- La generación de sitios estáticos con caché agresivo es esencial para evitar la dependencia en tiempo de ejecución de la disponibilidad de Notion.
- Si tu proyecto demanda alto tráfico, datos relacionales complejos, actualizaciones en tiempo real o garantías estrictas de uptime, elige un CMS headless diseñado específicamente para ese propósito.
Qué significa realmente “Notion como backend”
Primero, distingue entre dos cosas diferentes: Notion Sites (su función de publicación integrada) y usar la API de Notion como capa de datos para tu propio frontend.
Notion Sites te permite publicar cualquier página con un clic. Es simple pero limitado: estás atrapado con el estilo y la estructura de dominio de Notion.
Usar Notion como un CMS headless es diferente. Construyes un frontend personalizado (típicamente con Next.js, Astro o similar), obtienes el contenido de la API de Notion y lo renderizas como quieras. Esta es la arquitectura que impulsa sitios como el ejemplo del portafolio de cantante de ópera: páginas estáticas con secciones dinámicas que extraen datos de un backend de base de datos de Notion.
La arquitectura típica
Un sitio web impulsado por Notion generalmente sigue este patrón:
- El contenido vive en bases de datos de Notion (publicaciones de blog, eventos, elementos de portafolio)
- Tu servidor o proceso de construcción llama a la API de Notion para obtener ese contenido
- Una capa de renderizado transforma la estructura de bloques de Notion en HTML
- Generación estática o ISR almacena en caché el resultado para que no estés consultando Notion en cada solicitud
Bibliotecas como react-notion-x manejan el paso de renderizado, convirtiendo los tipos de bloques de Notion en componentes de React estilizados. Obtienes callouts, bloques de código, tablas y toggles sin tener que construir cada uno por tu cuenta.
Dónde funciona bien esto
Usar la API de Notion para sitios web brilla en escenarios específicos:
Sitios de contenido pequeños y portafolios. Un calendario de eventos de un músico, una galería de proyectos de un freelancer o un tablero de empleos de una startup. Las actualizaciones de contenido son poco frecuentes, y la persona que actualiza no quiere aprender un nuevo CMS.
Prototipos y MVPs. Cuando necesitas algo en línea rápidamente y tu modelo de contenido es simple, Notion elimina el backend por completo. Puedes validar una idea antes de invertir en infraestructura adecuada.
Herramientas internas y documentación. Los equipos que ya usan Notion pueden exponer ciertas páginas externamente sin migrar contenido.
La propuesta de valor real: tu cliente no técnico edita contenido en una herramienta que ya usa diariamente. No se requiere capacitación.
Discover how at OpenReplay.com.
Dónde se desmorona
Aquí es donde las comparaciones de Notion vs. CMS tradicionales se vuelven honestas:
Los límites de tasa son estrictos. La API de Notion te limita a aproximadamente 3 solicitudes por segundo. Para la obtención en tiempo de construcción, esto significa que un sitio con 500 páginas tarda minutos en reconstruirse. Para la obtención en tiempo de ejecución, necesitas caché agresivo.
Las URLs de archivos expiran. Las imágenes y archivos alojados en Notion devuelven URLs temporales (típicamente válidas por una hora). Debes hacer proxy de estas a través de tu propio servidor o descargarlas y re-alojarlas durante el tiempo de construcción.
Algunos tipos de bloques no están soportados. La API no devuelve todo lo que ves en Notion. Los bloques sincronizados, ciertas incrustaciones y algunas vistas de base de datos pueden renderizarse incorrectamente o no renderizarse en absoluto.
Los webhooks son solo de señalización. Los webhooks de Notion te dicen que algo cambió pero no incluyen los datos reales. Aún necesitas volver a obtener el contenido después de recibir una notificación.
Sin consultas relacionales. A diferencia de una base de datos real, no puedes hacer joins entre bases de datos de Notion de manera eficiente. Los modelos de contenido complejos se vuelven dolorosos.
Notion puede caerse. Si estás obteniendo datos en tiempo de ejecución y la API de Notion no está disponible, tu sitio se rompe. La generación estática con fallbacks mitiga esto, pero sigue siendo una dependencia que no controlas.
Cuándo elegir algo más
Omite Notion como backend si necesitas:
- Sitios de alto tráfico que requieren respuestas consistentes de menos de 100ms
- Datos relacionales complejos (productos con variantes, categorías anidadas)
- Actualizaciones de contenido en tiempo real sin retrasos de reconstrucción
- Garantías estrictas de uptime
- Grandes volúmenes de contenido (miles de páginas)
Para estos casos, plataformas de CMS headless diseñadas específicamente o una base de datos simple con una interfaz de administración te servirán mejor.
Conclusión
Notion funciona como un CMS headless ligero para sitios pequeños, herramientas y MVPs donde la experiencia de edición importa más que la escala. La arquitectura es directa: obtén datos en tiempo de construcción, almacena en caché agresivamente y maneja las peculiaridades de la API con una biblioteca de renderizado.
Simplemente no lo confundas con una base de datos de producción. Conoce los límites de tasa, planifica para las URLs que expiran y ten una ruta de migración lista si tu proyecto lo supera.
Preguntas frecuentes
Notion devuelve URLs de archivos temporales que típicamente expiran después de una hora. La solución más confiable es descargar todas las imágenes durante tu paso de construcción y servirlas desde tu propio alojamiento o un CDN. Alternativamente, puedes configurar un proxy del lado del servidor que obtenga y almacene en caché las imágenes bajo demanda, refrescándolas antes de que expiren.
Notion no es adecuado para comercio electrónico. Carece de consultas relacionales necesarias para productos con variantes, no tiene soporte transaccional, y sus límites de tasa hacen que las actualizaciones de inventario o precios en tiempo real sean imprácticas. Un CMS headless diseñado específicamente o una base de datos emparejada con una interfaz de administración es una opción mucho mejor para cualquier tienda.
Si obtienes contenido en tiempo de ejecución, tu sitio se romperá cuando la API de Notion no esté disponible. La mitigación estándar es usar generación de sitios estáticos para que las páginas se pre-construyan y se sirvan desde un CDN. La Regeneración Estática Incremental con fallbacks de stale-while-revalidate también ayuda al servir contenido en caché mientras se intenta refrescar en segundo plano.
Puedes implementar colas de solicitudes con retrasos para mantenerte dentro del límite de aproximadamente tres solicitudes por segundo. Almacenar en caché las respuestas de la API localmente entre construcciones para que solo las páginas modificadas se vuelvan a obtener también ayuda significativamente. Para sitios muy grandes, considera una capa de datos intermedia que se sincronice con Notion en un horario en lugar de consultar la API en tiempo de construcción.
Understand every bug
Uncover frustrations, understand bugs and fix slowdowns like never before with OpenReplay — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.
