Lo que preparé antes de publicar mi primera web personal (kimura512.dev)
Conclusión
Al publicar kimura512.dev por primera vez, lo que más tiempo consumió no fue programar funciones, sino lograr que un tercero pudiera leer y confiar en el sitio. Una web que solo funciona en local sin identidad clara del operador, sin canal de contacto ni política de privacidad resulta endeble como portafolio. Antes de abrir el acceso público, agrupé las páginas de Acerca de, Privacidad, Contacto y un lote inicial de artículos dentro del mismo hito.
1. Repositorio y control de compilación
En local las dependencias se fijan con pnpm; el flujo hacia producción consiste en ejecutar pnpm run build y después wrangler deploy. Las claves secretas se custodian exclusivamente en Cloudflare Workers Secrets y jamás se suben ficheros .env al repositorio. Para evitar incidencias, adopté una norma estricta: "No desplegar ningún commit que no supere la compilación en local". Lanzar pnpm build antes de cada push detecta desajustes de tipos y rutas antes de llegar a los usuarios.
2. Lista de comprobación visual previa al lanzamiento
Antes de cada publicación compruebo manualmente en el navegador que no queden tarjetas con la etiqueta "Próximamente", que las rutas con prefijos de idioma no arrojen errores 404, que las etiquetas OGP de redes sociales sean correctas y que el formulario de contacto envíe mensajes reales. Mantener este listado por escrito evita despistes de última hora.
3. Umbral mínimo de contenido
Mostrar únicamente tarjetas de proyectos reduce el sitio a un escaparate superficial. Preparé varios artículos técnicos basados en experiencias reales para no inaugurar la web con entradas vacías. El baremo editorial fue sencillo: "¿Resulta esta lectura útil para quien afronte el mismo problema?" Disponer de textos sólidos desde el primer día genera confianza inmediata.
4. Verificación de red tras el despliegue
Una vez completado el despliegue, compruebo que el listado del blog, las lecturas individuales y la página de privacidad respondan con código HTTP 200 en el dominio principal. Aunque la indexación en motores de búsqueda pueda gestionarse más adelante, es prioritario detectar directivas noindex involuntarias. Examinar el código fuente en ventanas de incógnito evita la distorsión del caché.
5. Unificación de dominios y canal de contacto
Todos los mensajes se canalizan a través de info@kimura512.dev, haciendo coincidir el destino del formulario con los textos del pie de página y la sección Acerca de. Las discrepancias en las direcciones de contacto suscitan desconfianza. En cada versión realizo un envío de prueba para validar la entrega de extremo a extremo.
6. Coherencia en la navegación general
El pie de página ofrece acceso directo a Blog, Acerca de, Privacidad y Contacto desde cualquier punto de la web. Los proyectos inacabados se retiran de la portada, permitiendo que un visitante nuevo acceda a toda la información relevante en un par de clics.
7. Paridad entre local y producción
La recarga rápida del entorno local suele ocultar particularidades del enrutamiento en producción. Las redirecciones lingüísticas y el envío de correos mediante endpoints API en Workers deben verificarse tras compilar para producción real.
8. Especialización de portada y artículos
La portada resume los proyectos finalizados, mientras que las explicaciones detalladas y la toma de decisiones técnicas pertenecen al blog. Durante la primera semana posterior al estreno congelé las nuevas funciones para centrarme exclusivamente en corregir erratas, revisar enlaces rotos y pulir la redacción legal.
Resumen
El primer lanzamiento no requiere perfección matemática, sino capacidad de explicarse con claridad ante el público. Sincronizar infraestructura, textos legales y contenido en un mismo bloque aporta solidez a largo plazo.
Preguntas frecuentes
Q. ¿Cuál es la ruta más rápida para publicar con solvencia?
Reunir Acerca de, Privacidad, Contacto, dos artículos de fondo y la retirada de proyectos a medio hacer en un solo sprint. Con esa base lista, el mantenimiento resulta fluido.
Q. ¿Cuántas pruebas se realizaron antes de apuntar los DNS?
Tres despliegues en Workers de previsualización y dos comprobaciones completas tras delegar el dominio principal. Apoyarse en entornos previos previene fallos en producción.