Moving kurtisjustin.co.uk to a CMS
An in-progress migration from a code-first personal site to a CMS-backed setup, so publishing becomes fast and low-friction — without sacrificing performance, SEO control, or my existing URL structure.
Personal Website (kurtisjustin.co.uk) · 2026 - in progress · Product owner, delivery lead, and developer
Goals
- Make publishing content possible without touching application code
- Keep existing URLs stable (especially /case-studies and any indexed pages)
- Preserve SEO control: canonical tags, metadata, schema, sitemap output
- Keep performance strong (fast loads, minimal client-side bloat)
- Maintain staging safety (noindex + analytics/ads suppression)
- Keep accessibility standards (structured content, headings, keyboard navigation)
Constraints
- No breaking changes to current public routes (avoid 404s and SEO regressions)
- Keep ‘no trailing slashes’ policy consistent across the site
- Hosting remains on DigitalOcean App Platform + Cloudflare
- Avoid turning the site into a complex platform with heavy dependencies
- CMS choice should fit the reality: a personal site that still needs proper engineering
Problem
Right now, the site is easy for me to change as a developer — but it’s still a developer workflow. New case studies, edits, and content tweaks are competing with ‘real dev work’ (and my tendency to overthink structure). The result: I build loads, but I publish less than I want.
I’m moving to a CMS because I want content to be something I can ship regularly — like a habit — rather than a mini project every time.
Approach
Phase 0: Define the ‘why’ and success criteria (you are here) - Write this case study as the living brief. - Define what ‘done’ looks like: publishing flow, SEO behaviour, performance, staging guardrails.
Phase 1: CMS selection and architecture plan - Choose a CMS style that fits: - **Headless CMS** (content via API) - **Git-based CMS** (content in repo, edited via UI) - **Hybrid** (content in repo with optional hosted UI) - Decide content source approach per environment (staging vs prod).
Phase 2: Content model and migration scope - Start with **case studies** as the first content type. - Map existing JSON model to CMS fields. - Define required fields vs optional fields.
Phase 3: Implement the content pipeline - Add a content fetching/loading layer. - Add validation (schema) so bad content can’t break pages. - Ensure filtering/search still works (query params stay the same).
Phase 4: SEO + sitemap parity - Ensure meta tags, canonical tags, Open Graph and JSON-LD behave identically (or better). - Ensure sitemap is generated from CMS content and includes all case study slugs.
Phase 5: Staging + publishing workflow - Staging is noindex and disables analytics. - Define how drafts work: - draft content visible in staging only - publish promotes to production
Phase 6: Rollout and hardening - Migrate remaining content types (about, CV, notes/blog if desired). - Add a small editorial checklist and content QA steps. - Add monitoring/validation to catch broken links or missing fields.
Implementation highlights
- Incremental migration plan (case studies first, then expand)
- Schema validation to keep CMS content safe and predictable
- SEO parity checklist (canonical, metadata, JSON-LD, sitemap)
- Staging workflow that supports drafts without indexing
- Publishing workflow designed around low friction and repeatability
Challenges
- Choosing a CMS that reduces friction without adding a load of complexity
- Maintaining URL stability and canonical consistency during migration
- Keeping performance strong if content becomes API-driven
- Avoiding ‘CMS creep’ (turning a simple site into an enterprise setup)
Results
- In progress — success will be measured by how quickly I can publish and refine case studies without touching code, while keeping SEO/performance stable.
What I'd do next
- Pick the CMS approach and lock the architecture (git-based vs headless)
- Start migration with case studies: map fields + implement content loader + keep routes stable
- Build the draft → staging → publish flow so I can ship content continuously
- Add a simple ‘SEO parity’ checklist to validate every migration step
How AI helped
This case study is deliberately being written before the build as a living brief. ChatGPT helps me clarify the why, define constraints, and break the project into sensible phases. Once the architecture is chosen, Codex will handle the implementation in repo-aware passes (content pipeline, schema validation, SEO parity, and staging guardrails), while I keep the final decisions and quality control manual.