Después de publicar la nueva versión de mi portfolio, quise revisar algo más específico que el diseño o el stack: si la web estaba preparada para ser rastreada, entendida e indexada correctamente.
No quería limitarme a añadir un título, una descripción y un sitemap. Mi objetivo era que cada página saliera publicada con una base SEO coherente desde el primer momento: URLs claras, metadatos consistentes, datos estructurados, alternates de idioma, buen rendimiento y una configuración que facilite el rastreo.
Este es el trabajo técnico que he hecho.
Diseñar la arquitectura pensando en búsquedas concretas
La primera decisión SEO no está en una etiqueta meta, sino en la arquitectura. Cada página tiene que responder a una intención concreta y tener una URL estable que pueda enlazarse, indexarse y medirse.
En mi portfolio esa estructura queda dividida en:
- Home.
- Sobre mí.
- Proyectos.
- Página individual para cada proyecto.
- Blog.
- Página individual para cada artículo.
- Contacto.
- Versiones en español e inglés.
Esto permite que cada URL tenga una intención más clara. Una página de proyecto puede posicionarse por el nombre del proyecto, por la tecnología usada o por el tipo de trabajo realizado. Un artículo puede posicionarse por una pregunta concreta. La home no tiene que resolver todas las búsquedas posibles.
Astro encaja bien en esta parte porque genera HTML estático por página. No necesito que Google espere a que una aplicación client-side pinte el contenido principal. El HTML ya llega con estructura, títulos, texto y enlaces.
Esa ventaja no convierte a Astro en la mejor opción para cualquier proyecto. En mi comparativa sobre Astro vs WordPress para una web profesional separo el control técnico de las necesidades reales de edición y mantenimiento.
Centralizar los metadatos
Una de las primeras piezas que construí fue un componente SEO reutilizable. En vez de repetir <title>, descripción, canonical, Open Graph, Twitter Cards y robots en cada página, todo pasa por una misma capa.
Esto me da tres ventajas:
- Evito olvidos entre páginas.
- Mantengo un formato consistente.
- Puedo cambiar una regla global sin editar medio proyecto.
Cada página recibe su título y descripción, pero el componente se encarga de completar lo demás: canonical, imagen social, theme-color, meta robots, Open Graph y Twitter.
Para una web pequeña puede parecer excesivo. En la práctica, cuando añades proyectos, blog e idiomas, centralizarlo evita errores muy fáciles de cometer.
Canonicals y trailing slash consistentes
Un detalle que parece menor, pero no lo es: las URLs tienen que ser coherentes.
En mi caso uso trailing slash de forma consistente. Eso significa que la URL canónica de una página termina siempre en /. El sitemap también genera las URLs con ese mismo formato.
La idea es evitar duplicados del tipo:
/proyectos/proyectos//proyectos/index.html
Si Google encuentra varias formas de acceder al mismo contenido, puede entenderlo, pero prefiero no hacerle trabajar de más. Una URL, una canonical, una versión clara.
Hreflang para español e inglés
El portfolio tiene versión en español e inglés, así que cada página emite sus alternates:
esenx-default
También el sitemap incluye esos alternates. Esto es importante porque no basta con traducir páginas. Hay que decirle a los buscadores qué versión corresponde a cada idioma y cuál es la versión por defecto.
En mi caso, x-default apunta a la versión española porque es el idioma principal del sitio.
Datos estructurados con JSON-LD
He añadido JSON-LD para que los buscadores entiendan mejor qué representa cada página.
La web incluye esquemas como:
Person, para identificarme como autor y profesional.WebSite, para describir el sitio.ProfilePage, en la home y sobre mí.CollectionPage, en listados como proyectos y blog.CreativeWork,SoftwareSourceCodeoWebApplication, según el tipo de proyecto.BlogPosting, en cada artículo.BreadcrumbList, para reforzar la jerarquía de navegación.
No espero que esto posicione por sí solo. Los datos estructurados no sustituyen al contenido. Pero sí reducen ambigüedad: ayudan a conectar autor, sitio, proyectos y artículos dentro de una misma entidad.
Sitemap dinámico
El sitemap no lo mantengo a mano. Se genera desde el contenido real del proyecto.
Incluye:
- Páginas estáticas.
- Proyectos.
- Artículos del blog.
- Fecha de última modificación.
- Frecuencia de cambio.
- Prioridad.
- Alternates de idioma.
Esto evita que el sitemap se quede desactualizado cuando publico un nuevo proyecto o artículo. Además, lo he acompañado con una hoja sitemap.xsl para que, si alguien lo abre en el navegador, no vea solo XML plano sino una tabla legible.
El sitemap no hace magia, pero facilita el rastreo. Y en una web que va creciendo con contenido, mantenerlo automatizado es una decisión sana.
Robots.txt sin bloquear recursos importantes
El robots.txt permite rastrear el sitio y apunta al sitemap. También deja explícito que los bots de IA y buscadores pueden acceder al contenido.
Un punto importante: no bloqueo /_astro/. Ahí viven assets generados por Astro, como CSS y JavaScript. Si bloqueas esos recursos, Google puede tener más problemas para renderizar la página como un usuario real.
Sí bloqueo /api/, porque no es una zona que quiera exponer al rastreo si en el futuro añado endpoints.
Archivos llms.txt y llms-full.txt
Además del SEO clásico, he añadido llms.txt y llms-full.txt.
La idea es sencilla: ofrecer una versión estructurada del contenido para asistentes de IA. llms.txt funciona como índice corto del sitio y llms-full.txt reúne más contexto en formato Markdown.
No es un estándar equivalente a robots.txt, pero me parece útil para una web personal. Si alguien busca información sobre mí o mis proyectos a través de un asistente, quiero que el contenido sea fácil de encontrar, citar y resumir correctamente.
Los he dejado accesibles, pero configurados para que funcionen como archivos de apoyo y no como páginas principales del sitio.
Rendimiento como parte del SEO
El SEO técnico no es solo etiquetas. También importa cómo carga la web.
Por eso tomé varias decisiones:
- Usar Astro para generar HTML estático.
- Evitar convertir todo en una SPA.
- Reducir JavaScript en el cliente.
- Servir la fuente Inter localmente.
- Organizar Sass en una arquitectura mantenible.
- Cachear assets generados por Astro durante mucho tiempo.
- Evitar animaciones pesadas que no aportaban al contenido.
Mi portfolio anterior tenía más efectos visuales. Este es más sobrio, pero carga mejor y es más fácil de mantener. Para una web profesional, prefiero que el contenido sea rápido, claro y rastreable.
Configuración del hosting
También he revisado la configuración del hosting para que cada tipo de recurso se sirva correctamente.
En la práctica, esto significa cuidar tres cosas:
- Que los archivos técnicos tengan el tipo de contenido correcto.
- Que los recursos estáticos puedan cachearse sin perjudicar actualizaciones importantes.
- Que la configuración global no bloquee archivos necesarios para renderizar o rastrear la web.
No es la parte más visible del SEO, pero puede afectar bastante. Un sitemap mal servido, un recurso bloqueado o una caché demasiado agresiva pueden crear problemas difíciles de detectar si solo miras el HTML.
Contenido antes que trucos
La parte técnica ayuda, pero no sustituye al contenido. Para que el portfolio tenga más posibilidades de posicionar, necesitaba páginas con texto real, no solo tarjetas bonitas.
Cada proyecto tiene su propio contexto:
- Qué problema resolvía.
- Qué rol tuve.
- Qué stack usé.
- Qué aprendí.
- Qué mejoraría.
Eso convierte cada proyecto en una página útil, no solo en una captura con un enlace. Lo mismo ocurre con el blog: escribir sobre decisiones reales del proyecto me permite crear contenido conectado con mi experiencia.
Qué he aprendido
La principal conclusión es que el SEO técnico funciona mejor cuando forma parte de la arquitectura desde el principio.
No es añadir un plugin, generar un sitemap y olvidarse. Es tomar decisiones coherentes:
- URLs claras.
- HTML renderizado.
- Metadatos consistentes.
- Contenido estructurado.
- Buen rendimiento.
- Recursos accesibles para bots.
- Datos estructurados.
- Sitemap y robots alineados.
- Una configuración de hosting que no bloquee el rastreo.
Mi objetivo no era perseguir atajos, sino construir una base sólida. Si publico más proyectos y artículos, el sistema ya está preparado para que cada nueva página salga con una estructura SEO correcta desde el primer momento.