From Google Sites to Cloudflare Pages: a build log
This site moved from a basic Google Sites presence to a custom Hugo build on Cloudflare Pages in about two and a half weeks, with 120 commits between 2026-02-03 and 2026-02-20.
TL;DR
- Built a full Hugo site skeleton quickly, then spent most of the time on structure, not visuals.
- Reworked the
/aistream into/machineyearning, including URL and nav cleanup. - Fixed repeated content bugs in templates (
summaryduplication, hidden body blocks, feed rendering mismatches). - Hardened publishing for iPhone + Obsidian + Working Copy by moving deploy responsibility to GitHub Actions + Cloudflare.
- Ended with a cleaner feed strategy (
/feed.xml), better typography/link handling, and a stable deploy workflow.
2026-02-03 to 2026-02-04: from blank repo to real site shape
The first two days were pure construction. The repo started with an initial commit, then moved through rapid changes to icons, social links, Hugo setup, homepage layout, and navigation. That pace was messy, but useful. It answered the core question fast: does this stack feel right for daily writing and publishing?
By 2026-02-04, the basic architecture was set:
- Hugo as the generator.
- A simple homepage and blog structure.
- A projects area.
- Early routing for the AI journal stream.
Session prompts in this window also made the intent explicit: this was a migration from Google Sites to a calmer, more durable, self-owned publishing setup.
2026-02-05 to 2026-02-06: content model, templates, and authoring friction
This phase had the highest churn and the highest leverage. The commits show repeated work on:
- HTML-in-Markdown rendering for AI entries.
- Summary ordering and
<!--more-->behavior. - Template experiments for AI layout variants.
- Blog filename/date cleanup.
- Feed composition and social metadata.
- Image hygiene rules and workflow snippets.
This is also where mobile authoring constraints became obvious. Session notes show iA Writer and iOS file extension friction, plus the need to keep templates predictable enough for fast phone-driven publishing.
The output of this phase was not “finished design.” It was a repeatable content contract:
- predictable front matter
- stable summary break behavior
- consistent image paths
- enforceable date/image checks
2026-02-11 to 2026-02-13: workflow hardening and deployment reliability
After a few days away from core structure work, the project moved into operational stability:
- Obsidian/Working Copy flow adjustments.
- Sync and rebase cleanup.
- Font and typography consistency fixes.
- Bug fixes for missing AI content and duplicated summaries.
Then deployment became the main story. Commits on 2026-02-13 added and refined GitHub Actions deployment for both Staging and main, upgraded Hugo for permalink compatibility, normalized Cloudflare project slug usage, and added preflight diagnostics for clearer failure visibility.
This was the turning point from “site that works locally” to “site that can be edited from iPhone and still deploy safely.”
2026-02-13 to 2026-02-14: renaming and URL permanence
A major editorial/architecture decision landed here: move from /ai naming to /machineyearning.
The migration included:
- moving entries into
/machineyearning - canonicalizing URLs
- adjusting breadcrumbs and back navigation
- removing outdated second-entry artifacts
- documenting root-level permanence policy for project URLs
This did two things at once: improved reader-facing language and reduced future URL churn.
2026-02-18 to 2026-02-20: polish, small fixes, and expansion
Final commits in this range were smaller but important:
- blog touchups and typo passes
- feed simplification to
/feed.xml - Mercury link fix
- adding the external Stationery Object project
- preview startup quality-of-life improvements
- retry logic around Cloudflare preflight in deploy workflow
At this point, the build had crossed from setup mode into maintenance mode.
Where it landed
The result is a simpler and more controllable publishing system than where it started:
- static generation with Hugo
- Cloudflare Pages deployment with explicit branch behavior
- session-informed workflow rules for previews and account safety
- project sections that can evolve without breaking canonical paths
The biggest gain was not visual polish. It was operational confidence: the site can now be written, edited, and shipped across desktop and iPhone workflows without losing structure.