Despliegue en Netlify
Publicar el output construido de Chinaski en Netlify es posible; el builder ya emite reglas de redirect en formato Netlify; pero el repo no incluye ningún pipeline específico para Netlify, así que esta página documenta la mecánica verificada y los dos caveats que hay que revisar antes de enviar ahí.
Qué produce el builder
En cada build, la raíz del output gana un archivo _redirects que contiene tus reglas de redirect en el formato propio de Netlify; líneas simples de old-slug new-slug status-code, conectadas a los redirects que gestionas en el admin (el build log dice "N Netlify redirect rule(s) written" cuando existen reglas). Esta es la superficie principal de compatibilidad con static hosts: build, luego sube el directorio, y tus redirects simples de path funcionan tal cual.
Todo lo demás son archivos ordinarios: árboles de output por idioma con archivos index.html, las piezas del PWA (sw.js, manifest, página offline), sitemaps y feeds, y el árbol de la carpeta de media.
Caveat 1; la línea del dominio canónico
Cuando un Site URL está fijado, el builder también apunta una regla de dominio canónico a _redirects que hace 301 del host alternativo www/sin www hacia tu canónico. Su marcador final ! es sintaxis de redirect de Caddy, no de Netlify. Si envías a un parser estricto de Netlify, revisa esa línea generada antes de enviar; elimínala o reescríbela según la gramática de reglas de redirect de Netlify. (El resto de _redirects; pares de path planos con status codes numéricos; está en el formato estándar.)
Caveat 2; los redirects con patrón no van en el archivo
Los redirects con patrón (wildcards con sustituciones) deliberadamente nunca se escriben en _redirects; el formato simple de archivo no puede expresarlos de forma segura. Si tu site depende de reglas con patrón, esas necesitan implementarse en el host en lugar de viajar en el archivo.
Alcance del static hosting: lo que un static host puro no puede ver
Dos features del CMS no existen en el output estático y deben llegar al propio CMS:
- Los envíos de formularios hacen POST a
/forms/<slug>en el CMS. En un static host no hay destino; a menos que fijes el base URL del CMS, en cuyo caso los shortcodes[form:slug]embebidos se renderizan como iframes apuntando al formulario alojado en el CMS, y los envíos aterrizan donde el CMS sea alcanzable. - Las descargas de documentos se sirven dinámicamente (conteo de descargas y estado de publicación); un deploy solo estático no puede servirlas; la feature de documentos requiere la ruta dinámica de proxy.
En corto: el hosting en Netlify es viable para sites de contenido puro; los sites cargados de formularios o documentos necesitan el CMS alcanzable (vía base URL) u otro modelo de hosting.
Pipelines
No hay un deploy target "push a Netlify" integrados; los deploys salientes integrados son rsync-over-SSH y buckets S3-compatibles (Settings → Deploy). Para llevar los builds a Netlify conectas tu propio conveyor (CLI/config de Netlify, un pipeline basado en repo, o una subida scriptada) disparado después de cada build; el directorio de output más _redirects es el artifact autosuficiente, re-emitido por completo en cada build.
Caveats del modo de idioma: un site desplegado en modo URL por subdominio necesita targets de deploy separados por subdominio de idioma; los sites en modo path se despliegan como un solo árbol.
Una nota sobre headers
Los comportamientos de cache en los ejemplos estáticos incluidos (cache corto en HTML, inmutable en las fonts .woff2, no-cache en sw.js) se implementan en los archivos de ejemplo de reverse-proxy para tu propio server, no horneados en el build. En un static host gestionado, las reglas de headers son un asunto de configuración del host; aplícalas ahí según el sistema de reglas de tu proveedor.