Proyecto propio · desarrollo y contenido
marvic.dev: arquitectura y contenido de una web propia
Este caso documenta la implementación de marvic.dev, no un encargo para un cliente. Su objetivo es explicar decisiones que pueden revisarse en el propio sitio, sin atribuirles resultados comerciales todavía no medidos.
El reto: explicar una oferta sin duplicar contenido
La web necesita presentar siete líneas de servicio, orientar a quien llega y ofrecer una vía de contacto. La home debe resumir la propuesta; cada ficha de servicio debe aportar profundidad sin repetir el mismo cuerpo de texto.
El blog añade guías de decisión relacionadas con servicios reales. La arquitectura tiene que permitir ese crecimiento sin convertir cada publicación en lógica nueva del layout global.
Decisiones y sus límites
Astro para composición y páginas estables
La home, los servicios, el blog y este caso se generan como páginas estáticas. El contacto y su API se ejecutan en el servidor. Esto mantiene HTML disponible para las rutas editoriales, pero exige un entorno Node operativo para el formulario.
JSON breve y MDX editorial
La navegación, los metadatos comunes y los bloques cortos viven en una fuente de copy global. Las fichas largas y los artículos usan Content Collections con esquema. Separar estas responsabilidades evita duplicación, aunque los cambios de contenido siguen requiriendo generar y publicar una nueva versión.
Tailwind para composición, CSS para comportamiento
El layout se apoya en utilidades y tokens compartidos. Los estilos editoriales, las superficies y la gestión de movimiento quedan en CSS o componentes específicos. La decisión busca consistencia; no significa que cualquier animación o efecto sea necesario.
Publicación editorial explícita
Las entradas de blog tienen categoría, cluster, fecha y servicio relacionado. Los borradores y las fechas futuras se excluyen de las rutas, el índice y los feeds. La publicación es estática: una fecha programada no sustituye un despliegue.
Contacto con alternativa sin JavaScript
El formulario envía a un endpoint que valida datos y utiliza SMTP cuando está configurado. Con JavaScript muestra estados en la misma página; sin él redirige al contacto con un estado renderizado en servidor. Una prueba de validación no demuestra recepción en el buzón.
Qué se ha comprobado y qué falta
Implementación y publicación verificadas
- La generación local resuelve los siete servicios, el blog con tres guías y sus metadatos.
- Los checks automatizados revisan encabezados, canonicals, enlaces internos, feeds y datos estructurados generados.
- El endpoint de contacto se puede comprobar con solicitudes inválidas sin enviar correo real; los estados de retorno se renderizan en el servidor.
- El 1 de octubre de 2026 se verificó la publicación de la versión 1f8609f: 17 URLs públicas respondieron con HTTP 200, incluidos los siete servicios y las tres guías de blog.
Validación operativa pendiente
- Confirmar la recepción real del formulario con la configuración del entorno de producción.
- Obtener una línea base en Search Console y datos de campo de rendimiento cuando exista cobertura suficiente.
- Revisar de nuevo las redirecciones de host, los canonicals y la configuración del servidor después de cada cambio de publicación.
Una compilación correcta y las pruebas locales son evidencia de implementación, no prueba de resultados comerciales, indexación o rendimiento real de visitantes.