Case study: cómo construimos el sitio de Comway

Este post es meta: explica las decisiones técnicas detrás del sitio en el que lo estás leyendo. Lo publicamos porque a veces el mejor argumento de capacidad técnica es contar bien lo que hicimos —con criterio, con números, con honestidad sobre los compromisos.

Contexto

Comway opera dos entidades societarias separadas, una en Argentina (Comway SRL) y otra en Paraguay (Comway SA). Son empresas hermanas pero no se cruzan societariamente. Cada una tiene su catálogo de servicios, su realidad regulatoria y su mercado.

El sitio anterior era un WordPress unificado, lento, con SEO mediocre, y problemas conocidos:

• Tiempos de carga elevados especialmente en mobile.
• Plugins de seguridad agregando overhead constante.
• Migración de contenido legal entre países complicada.
• Multi-idioma vía plugins poco mantenibles.
• Mantenimiento mensual significativo (parches, plugins, backups).

Decidimos rehacerlo de cero. Estos fueron los criterios y las decisiones.

Criterios de diseño

1. Performance no negociable: Core Web Vitals en verde móvil y desktop.
2. Multi-país real: separación clara entre Argentina y Paraguay, sin cruces de datos legales ni sociétarios.
3. Multi-idioma: español (default), inglés, portugués, chino. Hreflang correcto.
4. SEO técnico fuerte: structured data por entidad, sitemap multi-idioma, canonicals correctos.
5. Sin servidor que mantener: hosting estático.
6. Mantenible por una persona técnica part-time, no por un equipo dedicado.
7. Tipografía y diseño alineados con la madurez visual del sector telco/IT (Cisco, Cloudflare, Anthropic como referencias).

Stack final

• Astro 6 como framework.
• Tailwind CSS v4 para estilos.
• MDX para contenido enriquecido (blog y legales).
• Content Collections con schema Zod.
• TypeScript estricto.
• Bun como package manager (más rápido que npm/yarn en builds locales).
• GoDaddy Web Hosting como hosting (estático sobre cPanel Linux).

Decisiones clave y por qué

Decisión 1 — Astro sobre Next/Nuxt/SvelteKit

Para un sitio que es mayormente contenido, Astro genera HTML estático con JS mínimo. Next.js y similares serían over-engineering: cargan más JS por defecto, pesan más, y la complejidad operativa es mayor. Astro optimiza exactamente para el caso de uso: sitio corporativo con secciones interactivas puntuales.

Decisión 2 — Routing multi-país basado en URL

Las URLs son explícitas:

• comway.com.ar/ → home Argentina (español)
• comway.com.ar/en/ → home Argentina (inglés)
• comway.com.ar/py/ → home Paraguay
• comway.com.ar/py/en/ → home Paraguay (inglés)

(En producción se separan en dominios distintos vía deploy-time config.)

Cada país tiene su propio árbol de páginas en src/pages/ar/ y src/pages/py/. Esto evita que un cambio en una entidad afecte por accidente a la otra. Separación física > separación lógica para algo que importa legalmente.

Decisión 3 — Hreflang y canonical correctos

Para evitar canibalización SEO entre Argentina y Paraguay (o entre idiomas), implementamos:

• <link rel="canonical"> apuntando a la versión definitiva.
• <link rel="alternate" hreflang="es-AR"> / hreflang="es-PY"> / hreflang="en-US"> etc., consistentes en todas las páginas.
• Sitemap XML con namespace xhtml:link que declara las alternativas, según Google Search Central.

El @astrojs/sitemap lo automatiza con configuración mínima.

Decisión 4 — Layouts por país

Hay un CountryLayout.astro que recibe country: 'ar' | 'py' y renderiza el header común pero un CountryFooter distinto, con datos fiscales correspondientes (CUIT/RUC, dirección, condiciones de servicio). El componente CountryStructuredData.astro emite el JSON-LD Organization correspondiente, sin cruzar referencias entre las dos entidades.

<CountryLayout country="ar" title="..." description="...">
  <slot />
</CountryLayout>

Decisión 5 — Content Collections para legales y blog

Los documentos legales (privacidad, términos, cookies, SLA, etc.) se mantienen como archivos .md en src/content/legal-ar/ y src/content/legal-py/. Esto:

• Permite versionar legales con git.
• Hace trivial revisar diff cuando legales actualiza un texto.
• Cumple compliance: queda auditable quién cambió qué y cuándo.

El blog (esta misma entrada) usa Content Collection blog con schema Zod fuerte: cada post declara metadatos (categoría, tags, sources, fecha) validados en build. Si un post tiene mal formato, el build falla: no llega rotos a producción.

Decisión 6 — Tailwind v4 sobre v3

Cuando arrancamos el rediseño, Tailwind v4 ya estaba estable. Las ventajas de v4 (CSS-first config, container queries nativas, performance) compensaban el costo de adoptar una versión recién salida. La paleta del sitio se define en CSS:

@theme {
  --color-brand-primary: oklch(0.62 0.17 240);
  --color-brand-secondary: oklch(0.72 0.13 200);
  --font-display: 'Montserrat Variable', sans-serif;
  --font-body: 'Inter Variable', sans-serif;
}

Esto es directamente legible por diseñadores no-técnicos (es CSS estándar) y portable a otros sistemas si en algún momento dejáramos Tailwind.

Decisión 7 — Tipografía variable

Inter Variable y Montserrat Variable como fuentes principales (vía @fontsource-variable). Una sola request por familia, todas las weights y axes disponibles. Bajo costo en network, alta flexibilidad tipográfica.

Decisión 8 — View Transitions con ClientRouter

Astro provee <ClientRouter /> que habilita transiciones de página suaves usando la API nativa de View Transitions. El sitio se siente como SPA sin ser SPA: el contenido cambia con animación pero cada navegación es a una URL real, indexable.

Decisión 9 — Hosting estático en cPanel

Astro builda a dist/ con HTML, CSS, JS y assets. Lo subimos a GoDaddy vía SFTP. Ventajas:

• No hay servidor con runtime que mantener.
• Backup = clonar el repo git.
• TTFB típico bajo 200 ms desde Argentina.
• Cero costo extra de hosting (incluido en el plan ya contratado).

Compromiso: features que requieren server-side (formularios con validación dinámica, A/B testing) los implementamos vía endpoints externos (form handler en una Cloudflare Function aparte).

Decisión 10 — Sticky UI minimalista

Componente StickyUI.astro con WhatsApp directo y botón de contacto en bottom-right, presente en todas las páginas pero sin ser invasivo. Para sitio con vocación comercial B2B, reduce fricción para contactar.

Métricas resultantes

Sin entrar en cifras absolutas que dependen de la red del visitante, los resultados verificables:

• LCP móvil: en verde (≤ 2.5s) en home y páginas de servicio.
• CLS: prácticamente 0 (sin layout shifts notables).
• INP: en verde (≤ 200 ms) en todas las interacciones.
• Total JS servido a página inicial: bajo, mayormente Astro hydration de islas.
• Tiempo de build completo: en el orden del minuto, lo que permite previews en cada commit.

Lo que cambió en el flujo de trabajo

Para contenido

• Editar un post de blog = crear/editar un .mdx. Las herramientas son las mismas que las de un dev (editor de texto, git).
• Cambios pasan por PR que muestra preview.
• Una vez merged, deploy automatizable.

Para diseño

• Tokens de diseño en CSS, sin tocar JS.
• Cambios de paleta o tipografía = cambiar variables en theme.
• Componentes en src/components/*.astro, simples de localizar.

Para legales

• Modificar un documento legal = cambiar un .md.
• Diff queda en historial git para auditoría.
• Sin riesgo de “el plugin de WordPress se rompió y se perdió la edición de hace tres semanas”.

Lo que no resolvió

Honestidad: el stack no resuelve todo. Lo que requiere otra capa:

• Captura de leads avanzada (CRM, scoring): externa al sitio.
• Live chat con persona real: integración con plataforma externa (WhatsApp Business o similar).
• Analytics avanzado (eventos custom, funnels): GA4 / Plausible / Umami según preferencia de privacidad.

Conclusión

El sitio es producto de criterios explícitos: performance no negociable, separación legal entre países, mantenibilidad sin equipo dedicado. Astro + Tailwind v4 + Content Collections fue la combinación que mejor encajó. No fue por moda; fue por encaje. Y por eso lo recomendamos para sitios similares —con los matices que cada caso pida.

Si te interesa cómo aplicaríamos este criterio a tu sitio, escribinos.

Fuentes y referencias

• Astro Documentation
• Astro i18n Routing
• Tailwind CSS v4
• Google Search Central — Hreflang

Fuentes

• Astro Documentation
• Astro i18n Routing
• Tailwind CSS v4
• Google Search Central — Hreflang