Cómo evolucioné este portafolio con Astro, SEO técnico y una arquitectura mantenible

El objetivo no es exhibir una puntuación perfecta aislada. Es demostrar cómo tomo decisiones sobre estructura, rendimiento, contenido y mantenimiento en un sitio real que sigue cambiando.

El problema que debía resolver

Una web personal puede quedar desactualizada rápidamente: proyectos mezclados, rutas duplicadas, textos que ya no representan el perfil profesional y componentes difíciles de mantener. En este caso también existía otro desafío: el diseño debía conservar una identidad visual fuerte sin convertir cada página en una aplicación pesada.

La evolución del sitio se organizó alrededor de cuatro objetivos:

• Presentar una marca personal reconocible sin convertir la navegación en un catálogo comercial.
• Mostrar proyectos con contexto técnico, no solo capturas y enlaces externos.
• Publicar contenido rastreable con URLs estables, metadata específica y datos estructurados.
• Mantener una base que permita corregir, ampliar o retirar funcionalidades sin acumular rutas legacy.

Por qué elegí Astro

Astro encaja con un portafolio donde la mayor parte del contenido puede entregarse como HTML estático. Las páginas no necesitan hidratar una aplicación completa para mostrar texto, proyectos o servicios; JavaScript queda reservado para interacciones que realmente lo justifican.

Esa decisión simplifica el despliegue y reduce trabajo innecesario en el navegador. También permite inspeccionar el resultado final del build, algo importante cuando se revisan canonicals, headings, enlaces internos, schema o contenido generado desde colecciones.

React sigue disponible cuando una interacción lo necesita, pero no es la unidad básica de todas las páginas. La arquitectura parte del contenido y suma comportamiento de forma selectiva.

Arquitectura por features

La estructura del repositorio separa rutas, pantallas, componentes compartidos y contenido editorial:

src/
├── pages/       # wrappers de rutas
├── features/    # implementación de cada pantalla o dominio
├── layouts/     # estructura global del documento
├── shared/      # header, footer, SEO y utilidades transversales
└── content/     # artículos y casos de estudio validados

Las rutas bajo src/pages/ se mantienen finas. La interfaz y el comportamiento viven cerca de la feature que representan; los elementos reutilizados por todo el sitio permanecen en shared. Esta separación hace que una página pueda evolucionar sin convertir los wrappers de Astro en archivos monolíticos.

El contenido editorial utiliza Content Collections. El frontmatter se valida antes del render y las páginas de blog o proyectos se generan desde una plantilla común. Eso reduce diferencias accidentales entre metadata, fecha visible, Open Graph y JSON-LD.

Rendimiento medido y verificable

La base técnica prioriza decisiones que pueden revisarse:

• HTML estático para las páginas de contenido.
• Fuentes locales con font-display: swap.
• Imágenes con dimensiones, formatos adecuados y carga diferida cuando corresponde.
• Componentes y estilos acotados por feature.
• JavaScript reservado para formularios, navegación y animaciones concretas.
• Build inspeccionable antes de desplegar.

Las métricas publicadas son resultados reales de PageSpeed Insights. Para que sigan siendo útiles, las acompaño con fecha, perfil y herramienta: una auditoría demuestra el estado del sitio en ese momento, no una garantía inmutable.

Auditoría actual: 11 de julio de 2026

Volví a medir la home publicada con PageSpeed Insights y Lighthouse 13.4.0. El informe compartido de PageSpeed Insights registró estos resultados de laboratorio:

Las capturas originales también se conservan porque documentan una versión anterior del sitio. En esa auditoría, escritorio obtuvo 100/100 en las cuatro categorías y móvil obtuvo 99 en rendimiento junto con 100 en accesibilidad, prácticas recomendadas y SEO.

PageSpeed indicó que todavía no hay suficientes datos de campo para esta URL. Por eso separo estos resultados de laboratorio de los datos de campo de Core Web Vitals y los complementaré con Search Console cuando exista una muestra suficiente. Google también aclara que una buena puntuación aislada no garantiza posicionamiento y que la experiencia debe evaluarse en conjunto: cómo entiende Google la experiencia de página.

Evidencia de implementación reproducible

La validación del proyecto se apoya en artefactos concretos del repositorio:

Estas comprobaciones no sustituyen las métricas de usuarios reales. Sirven para verificar que la base publicada sea coherente antes del deploy y que una mejora de contenido no rompa indexación, navegación o semántica.

SEO técnico integrado en la arquitectura

El SEO no está agregado como una lista de etiquetas al final del proyecto. Forma parte de las plantillas y de la estructura del sitio:

• Canonical absoluto en todas las páginas indexables.
• og:url y Twitter URL alineados con la URL canónica.
• Sitemap generado desde rutas reales.
• Redirects permanentes para URLs legacy con equivalente.
• noindex para recursos que deben seguir disponibles sin competir en resultados.
• Schema base para la entidad Nicolás Pirello y schema específico por tipo de página.
• Enlaces internos con URLs canónicas y anchors contextuales.

Durante la evolución del portafolio también se consolidaron rutas que competían por la misma intención. Por ejemplo, el catálogo de proyectos quedó bajo /proyectos/ y el servicio de desarrollo web utiliza una sola landing para Argentina, con Buenos Aires como señal secundaria. La decisión fue mejorar y fusionar, no conservar páginas legacy por comodidad.

Qué cambió desde la primera versión

La versión inicial priorizaba mostrar trabajos y tecnologías. La versión actual incorpora decisiones que aparecieron al usar el sitio como producto real:

1. Los proyectos principales pasaron a ser casos de estudio con objetivos, arquitectura y resultados.
2. El blog se migró a una colección validada y admite metadata editorial específica.
3. Se agregaron páginas de servicios sin convertirlas en el centro de la navegación principal.
4. La entidad personal se normalizó entre contenido visible, metadata y JSON-LD.
5. Se eliminaron stubs de redirects y rutas duplicadas en favor de respuestas HTTP reales.
6. La estructura semántica se corrigió para que el layout sea dueño del único main global.

Este historial es parte del valor del caso: no se trata de una maqueta cerrada, sino de una base que soporta correcciones y nuevas decisiones sin rehacer el sitio completo.

Lecciones aplicables a otros proyectos

Una métrica necesita contexto

Una puntuación sin fecha, dispositivo y herramienta se vuelve obsoleta. Es mejor documentar cómo se mide, conservar evidencia y separar datos de laboratorio de datos de campo.

Menos JavaScript también es una decisión de producto

No hidratar todo el sitio reduce complejidad, pero además obliga a decidir qué interacción aporta valor. En páginas editoriales, HTML y CSS suelen resolver la mayor parte de la experiencia.

La arquitectura debe facilitar el cambio

Organizar por features no mejora el sitio por sí solo. Su valor aparece cuando hay que mover una ruta, ampliar un schema o corregir una plantilla sin buscar responsabilidades dispersas por todo el repositorio.

El SEO técnico no reemplaza el contenido

Canonical, sitemap y schema ayudan a que una página sea rastreable y comprensible. La página todavía necesita una intención clara, evidencia propia y un texto que resuelva lo que promete.

Resultado

El portafolio funciona como presentación profesional y como caso técnico vivo. La implementación actual entrega contenido estático, permite validar el HTML final, organiza las pantallas por responsabilidad y mantiene SEO, accesibilidad y rendimiento dentro del flujo normal de desarrollo.

La conclusión más importante no es que el sitio alcance una cifra perfecta. Es que cada afirmación relevante puede vincularse con una decisión de código, una validación reproducible o una evidencia visible, y puede actualizarse cuando el proyecto cambia.