Internal product · Performance & technical SEO

A reversible website migration with every public route accounted for.

A first-party build note showing how the commercial Astro site moved from a subdirectory to the canonical root while a separate Next.js portfolio kept its own URL space.

Declared application boundary
Commercial/USA/*/*
Portfolio/CV/*/portfolio/*

One preferred host · explicit destinations · versioned release

Proof type
Internal product
Audience
Agencies planning a relaunch or path migration
Timeline
Build note and launch checkpoint recorded in July 2026; no client delivery duration is claimed.
Last reviewed

01 / Buyer and problem

The system had one clear job—and explicit limits.

The commercial website needed to become canonical at the domain root without erasing the technical portfolio that previously lived there. A blanket redirect would have mixed two products and sent useful legacy URLs to unrelated destinations.

Who this helps

The reusable value is the release discipline: inventory public paths, map them deliberately, align search signals, and retain a tested way back.

Exact role

First-party migration planning, Astro implementation, redirect configuration, release-gate checks, browser verification, and technical documentation for the site's own move.

Constraints

  • Keep the commercial Astro build and the preserved Next.js portfolio as separate applications.
  • Map known URL families to relevant final destinations and preserve query strings where verified.
  • Keep canonical, hreflang, internal-link, robots, and sitemap signals aligned with the final routes.
  • Make activation reversible and avoid claiming rankings, traffic, or lead outcomes before evidence exists.

Scope

  • Legacy and destination route inventory
  • Permanent redirect map
  • Canonical, hreflang, robots, and sitemap alignment
  • Static build and release validation
  • Versioned activation and rollback path
  • Public browser and endpoint checks

02 / Architecture

A visible path from input to controlled result.

  1. 01

    Legacy request

    Known commercial and portfolio URL families arrive at the preferred HTTPS host.

  2. 02

    Nginx route map

    Explicit permanent rules choose the matching commercial root path or preserved portfolio path.

  3. 03

    Separate applications

    Astro serves the commercial root while Next.js remains isolated under the portfolio mount.

  4. 04

    Release gate

    Static, endpoint, metadata, sitemap, browser, and rollback checks decide whether the candidate can stay active.

03 / Delivery process

The work, in the order it became verifiable.

  1. 01

    Inventory the public surface

    List commercial pages, portfolio routes, public assets, APIs, canonicals, and submitted sitemap URLs before moving anything.

  2. 02

    Name every destination

    Use explicit route families for commercial and portfolio content instead of redirecting the former site indiscriminately to the new homepage.

  3. 03

    Build an isolated candidate

    Generate and validate a complete static candidate while the existing release remains available.

  4. 04

    Activate with a rollback

    Switch the versioned release only after readiness checks and keep the previous release addressable.

  5. 05

    Verify public behavior

    Check response status, redirect destinations, query strings, metadata, sitemaps, APIs, and representative browser journeys.

04 / Decisions and tradeoffs

The useful part is why the boundary exists.

01

Explicit mappings instead of a blanket root redirect

Useful legacy pages should reach a relevant final destination rather than an unrelated homepage.

Tradeoff
The map takes longer to maintain and must be updated when public routes change.
02

Separate commercial and portfolio URL spaces

Each application keeps a coherent canonical home and can be released independently.

Tradeoff
The web server and release checks must understand both applications.
03

Versioned activation with retained rollback

A complete candidate can be verified before it replaces the previous release.

Tradeoff
Release automation is more involved than copying files in place.

05 / Evidence

What can be inspected—and what cannot be claimed.

Generated HTML
39 pages

Recorded in the original July 17 build note before that note expanded the route set.

Redirect sample
31 + 6 paths

The original checkpoint recorded 31 commercial and 6 portfolio legacy equivalents reaching their declared destinations with query strings retained.

Automated checks
131 + 126 + 126

The dated build note records unit checks plus Chromium and WebKit journeys for that release candidate.

Claim boundary
No growth claim

The case explicitly separates migration implementation evidence from rankings, traffic, revenue, savings, or lead results.

06 / Outcome and handoff

A documented, reversible migration implementation with declared route families, separate application boundaries, and an inspectable release method.

Technologies used

  • Astro
  • Next.js
  • Nginx
  • TypeScript
  • Playwright
  • XML sitemaps
  • JSON-LD

Planning a relaunch?

Map the release before moving the routes.

Bring the current URL structure and the intended destination. The first conversation can stay at the public-system level.

Book a 20-minute fit call