CYRUS’SCloud CornerTECHNOLOGY · TRUST · PERSPECTIVE
Home / CSP's / Architecture Field Notes: The Amplify Rebuild

Architecture Field Notes: The Amplify Rebuild

A practical account of rebuilding Cyrus’s Cloud Corner: preserving useful content, packaging a static site, moving the domain, and correcting a rendering failure seen by Google.

Field notes: a resilient static website illustrated with Design, Deliver, Diagnose, Verify
Field notes: a resilient static website — an illustrated overview of the topics on this page.

Published and sources reviewed: October 26, 2026 · Practical architecture guide

The design constraints

The redesign retained the site’s main navigation, original favicon, personal certificate image, and astrophotography collection. The goal was to make technical material easier to read through clearer hierarchy, larger type, relevant illustrations, and consistent page navigation.

The content expanded into practical AI and PQC guides, while Projects remained a discovery link from About. These were site-specific editorial decisions, not a claim that every portfolio should use the same information architecture.

Static delivery on Amplify

The release package contains a complete HTML document for each route, local assets, metadata, a sitemap, and robots.txt. Amplify serves the package, while explicit route rules connect clean addresses such as /pqc to their static files. This avoids depending on a client-side route change for the first readable page.

The custom domain uses Route 53 and an Amplify-managed certificate. During setup, a hostname association on an old CloudFront distribution prevented activation. Releasing that previous association allowed the new deployment to complete. DNS records and CloudFront hostname ownership are related but distinct concerns.

The Google rendering failure

Search Console later reported a Soft 404. The supplied tested-page HTML showed navigation and metadata, but only “Unable to load the page. Please refresh.” in the main content area. Its screenshot was also unstyled. That evidence identified a content-loss fallback, but did not identify the individual failed resource.

The repair preserved the existing static content when enhancement failed, restored it after interrupted rendering, bundled the startup dependencies and public page data, and embedded local styles in each page. Controlled tests confirmed that the homepage remained readable when startup was interrupted or its runtime was unavailable.

Field notes: a resilient static website — decision path: Design — Preserve structure and assets; Deliver — Static pages on Amplify; Diagnose — Inspect actual crawler output; Verify — Test failure and recovery
Field notes: a resilient static website — decision path · Conceptual diagram; see the worked example and references.

Tradeoffs and reusable lessons

Bundling public content and embedding styles simplify first-page dependencies, but increase payload size and require a disciplined rebuild when content changes. A larger site could instead hydrate smaller page-specific data while keeping the same readable static fallback.

Test raw HTML, normal browser behavior, missing resources, and crawler-rendered output separately. A page that works in one browser session may still fail during rendering elsewhere. Keep a known deployment artifact and treat the live Search Console test as evidence after publishing, not as a promise of indexing.

Implementation checklist

  • Preserve important routes and original assets.
  • Package complete static HTML per route.
  • Verify clean-route rewrites and real missing-page behavior.
  • Check hostname ownership before domain activation.
  • Keep content readable when enhancement fails.
  • Test normal and interrupted startup.
  • Review crawler HTML and screenshots after deployment.

Download the editable checklist (CSV) ↗

Continue exploring

Sources & further reading