Case study · Portfolio architecture

Portfolio SEO and i18n system

A production portfolio architecture designed for recruiters, search engines, assistive technology, and AI crawlers. The work turned localized pages, case studies, schema, navigation, and content discovery into one coherent static system.

Project proof

My role

  • Defined the localized content model, route strategy, internal-link structure, and recruiter-facing information hierarchy.
  • Wrote crawlable case-study content and aligned titles, descriptions, headings, service topics, and schema-ready article bodies.
  • Kept the architecture static-first so search engines and assistive technologies can read the same meaningful HTML as users.

Constraints

  • The site needed consistent UI across English, Spanish, and Arabic without introducing separate layout forks.
  • Localized content had to be complete enough to index, not partial labels around English body copy.
  • Performance and Lighthouse stability had to remain strong while adding richer content and more pages.

Key decisions

  • Used typed localized records so case-study pages, work cards, route generation, and schema content share one source of truth.
  • Linked every case study from both homepage and work index pages to keep discovery simple for users and crawlers.
  • Improved RTL typography and wrapping rules instead of hiding long localized content or shortening proof detail.
Project type
Astro portfolio and SEO system
Role
Frontend architect and technical writer
Primary focus
i18n, structured data, crawlability
Stack area
Astro, TypeScript, static rendering
  • Astro
  • Technical SEO
  • i18n
  • hreflang
  • Structured data
  • Static performance

Context

A portfolio has to do more than look polished. It must help recruiters understand role fit quickly, help search engines discover every important page, and help crawlers extract accurate structured meaning from static HTML.

The existing foundation already used Astro and strong metadata, but the site needed stronger localized content depth, clearer case-study entry points, consistent recruiter hierarchy, and crawlable relationships between homepage, work pages, articles, and language alternates.

Problem

Portfolio sites often fail when they treat SEO, i18n, accessibility, and performance as separate checklists. That creates pages that may validate technically but still feel thin, hard to navigate, or inconsistent across locales.

The challenge was to improve discovery and credibility without adding heavy JavaScript, visual instability, or a different UI model for each language.

  • Recruiters needed a faster path from hero message to proof, stack, experience, and case studies.
  • Localized pages needed equivalent structure, not partial copies with mixed-language sections.
  • Case studies needed clear role, constraints, decisions, outcomes, and related service signals.
  • Search engines needed stable canonical URLs, alternates, semantic headings, and structured data.

Approach

The architecture was treated as a content system, not a collection of separate pages. Reusable localized data powers homepage work cards, work index pages, dynamic case-study routes, page metadata, and structured content surfaces.

The implementation kept the important content in server-rendered HTML. Language switching, headings, links, cards, and case-study details remain crawlable without waiting for client-side hydration.

  • Used typed content records so every locale exposes the same page model and proof structure.
  • Kept case-study URLs predictable across English, Spanish, and Arabic routes.
  • Linked homepage work cards and index pages directly to detail pages for crawler and user reachability.
  • Used semantic sections, lists, breadcrumbs, and table-of-contents links to make pages easy to parse.

Localization and RTL decisions

Localization was handled as full page parity rather than translated labels only. Spanish and Arabic versions receive localized titles, descriptions, summaries, proof panels, outcomes, next steps, service tags, and page navigation.

Arabic typography required different spacing behavior from Latin content. The page rules avoid excessive letter spacing, preserve logical reading order, and allow long technical terms to wrap without causing horizontal overflow.

  • Localized visible content, metadata, accessibility labels, breadcrumbs, and CTA text.
  • Preserved one shared layout system while respecting `lang` and `dir` attributes.
  • Allowed technical terms such as Astro, TypeScript, SEO, and Core Web Vitals to remain readable inside Arabic copy.
  • Used static links and language alternates instead of runtime-only route switching.

Performance and SEO decisions

The system favors static rendering, typed data, predictable internal links, and minimal client-side behavior. This improves first paint reliability and makes the site understandable to search engines, accessibility tooling, and language-aware crawlers.

The case-study model also supports richer structured data because each page has explicit headings, sections, article body text, keywords, related services, and language-specific metadata.

  • Kept portfolio proof content server-rendered and available in the initial HTML response.
  • Avoided JavaScript-only content discovery for work, articles, and core navigation.
  • Aligned page titles, meta descriptions, H1s, section headings, and JSON-LD with the same localized topic.
  • Maintained Lighthouse-friendly layout stability by using stable spacing, responsive grids, and reduced motion rules.

Desktop lab results

A desktop Lighthouse 13.4.1 navigation run on September 10, 2026 measured the production homepage in Chrome 152 at 100 for Performance, Accessibility, Best Practices, SEO, and Agentic Browsing. It reported First Contentful Paint at 0.4 seconds, Largest Contentful Paint at 0.6 seconds, Total Blocking Time at 0 milliseconds, Cumulative Layout Shift at 0, and Speed Index at 0.8 seconds.

The measured transfer payload was 190 KiB and script boot-up time rounded to 0.0 seconds. These figures describe one desktop laboratory run, not field data, and do not guarantee results across mobile devices, networks, locations, browser states, or future deployments.

  • Performance: 100
  • Accessibility: 100
  • Best Practices: 100
  • SEO: 100
  • Agentic Browsing: 100
  • FCP: 0.4 s · LCP: 0.6 s · TBT: 0 ms · CLS: 0 · Speed Index: 0.8 s
  • Payload: 190 KiB · Lighthouse 13.4.1 · Chrome 152

Outcomes

  • A stronger recruiter journey from hero summary to proof, case studies, experience, and contact.
  • Six crawlable case-study pages per supported locale using one consistent content model.
  • Localized SEO surfaces across titles, descriptions, internal links, structured data, and page copy.
  • A maintainable architecture where future case studies can be added without duplicating page logic.

Next steps

  • Add verified search-console insights after enough production data exists.
  • Publish visual diagrams for the content and route model when useful for recruiters.
  • Continue expanding case-study topics around measurable product and engineering work.