Master Concept Website Migration Plan

Status Legend: DECIDED = confirmed approach

PLANNED = will implement

NOTED = recorded for future reference

ACTIVE = working on now

Table of Contents

Strategy & Decisions

1. Domains & Strategy DECIDED
2. Context & Goals DECIDED
3. Architecture Overview DECIDED
4. Tech Stack DECIDED
5. Hosting & Infrastructure DECIDED
6. Domain Routing (Transition) NOTED

CMS & Content

1. Payload CMS Features NOTED
2. Payload Plugins NOTED
3. Payload CMS vs WordPress NOTED
4. Block System & Templates NOTED
5. Internal Link Integrity NOTED
6. File & Media Management NOTED

Development Workflow

1. Local Development & Preview PLANNED
2. Git, CI/CD & Deployment PLANNED
3. Vibe Coding Workflow NOTED
4. 3-Layer Guardrails PLANNED

Migration

1. Migration Phases PLANNED
2. SEO Safety PLANNED
3. Converting Elementor Pages NOTED
4. Cross-Linking Blog & Landing Pages PLANNED

Integrations & Future

1. HubSpot Integration NOTED
2. AI-Automated SEO NOTED
3. WebMCP Readiness NOTED
4. Future Enhancements NOTED
5. Reference URLs

1. Domains & Strategy

DECIDED

Strategy: Build and test the new framework on a separate trial domain first. No changes to production during trial phase. Migration to masterconcept.ai happens later.

2. Context & Goals

DECIDED

Current: WordPress + Elementor on SiteGround (GoGeek shared hosting)

• Blog - managed by marketing team
• Landing pages - managed by Tommy

Problems:

• Elementor is not vibe-codeable (content stored as serialized DB data)
• AI cannot easily read, edit, or generate Elementor pages
• Performance issues and plugin conflicts
• No path to WebMCP integration

Goal: Modern, AI-friendly stack where:

• Landing page design is vibe-coded (AI edits code directly)
• All content editable in admin panel (no code needed for content)
• Blog stays on WordPress during transition
• Same domain, no broken links, no SEO loss

3. Architecture Overview

DECIDED

Front Door

GCP Cloud Run (hosted on GCP, auto-deploy via GitHub Actions)

Routing (Production - During Transition)

Routing approach TBD (see Section 6). Target:

Frontend Stack

API Consumers

Data Layer (All GCP)

3-Layer Guardrails

4. Tech Stack

DECIDED

5. Hosting & Infrastructure

DECIDED

GCP Resources (mcai- prefix)

Environment Variables

# Database
DATABASE_URI=postgresql://USER:PASSWORD@HOST:5432/mcai-payload

# Payload CMS
PAYLOAD_SECRET=your-random-secret-key-here
PAYLOAD_API_KEY=key-for-claude-code-access

# GCP Cloud Storage
GCS_BUCKET=mcai-media
GCS_PROJECT_ID=mcai-web

# App
NEXT_PUBLIC_SITE_URL=https://site.mcai.dev
NODE_ENV=production

Cost

All GCP services covered by free GCP credits.

Why Not Firebase?

Firebase App Hosting is just a wrapper around GCP Cloud Run. Since you already have GCP with credits, use Cloud Run directly - full control, no extra abstraction.

6. Domain Routing (Transition)

NOTED - approach not decided yet, will finalize when ready for production migration

The Problem

masterconcept.ai DNS points to SiteGround (WordPress). Need both WordPress (blog) and Cloud Run (new pages) on the same domain during transition.

Options Discussed

Option A: Cloudflare Worker (you have paid Cloudflare)

• Worker routes by URL path: /blog/* → WordPress, /* → Cloud Run
• No DNS changes, no email impact
• Needs domain admin to add Worker Route + enable proxy (orange cloud)

Option B: Cloud Run as reverse proxy

• DNS points to Cloud Run instead of SiteGround
• Next.js rewrites in config proxy blog paths to SiteGround
• Risk: if Cloud Run goes down, WordPress also unreachable

Option C: WordPress as front door

• WordPress stays as default, specific paths proxy to Cloud Run
• Lowest risk but more complex SiteGround config

Trial phase: Not applicable - trial domain points directly to Cloud Run. This decision only matters when migrating masterconcept.ai.

7. Payload CMS Features

NOTED

Core Architecture

• Lives inside your Next.js app (not a separate service)
• 100% TypeScript with full type safety
• Config-based: everything defined in code, version controlled
• Free & open source (MIT license)

Content Management (Like WordPress)

Content Modeling

• Collections: Pages, Posts, Media, Categories, Tags, Users, Forms
• Globals: Site Settings, Navigation, Footer (singleton data)
• Blocks Field: Modular content blocks (like Gutenberg but code-defined)
• 30+ field types: text, richText, number, date, relationship, array, group, blocks, tabs, upload, select, checkbox, and more
• Conditional logic: show/hide fields based on other field values

Admin Panel (/admin)

• Auto-generated UI from config - no manual admin building
• Live Preview: real-time side-by-side editing
• Rich Text Editor: Lexical-based, similar to WordPress Gutenberg
• Dark mode, white-labeling (custom logo/colors)
• Anyone can create pages from existing blocks - no code needed, just pick blocks and fill content

Authentication & Roles

API (3 Ways to Access Content)

• REST API - full CRUD, pagination, filtering
• GraphQL API - flexible queries & mutations
• Local API - direct database access from server code (Claude Code uses this)

8. Payload Plugins

NOTED

9. Payload CMS vs WordPress

NOTED

10. Block System & Templates

NOTED

Starting Point: Payload Website Template

npx create-payload-app@latest -t website

Pre-built blocks included:

shadcn/ui Block Library (Additional UI Components)

Hero sections, feature grids, pricing cards, testimonials, FAQ, CTA, footer, header/nav, stats, team cards, blog list, and more.

Custom Blocks Needed

Your html-widgets/ folder = block prototypes. Claude Code converts each to a Payload block component.

Why Blocks Are More Flexible Than WordPress

WordPress blocks output static HTML. Payload blocks are full-stack React components that can:

• Call external APIs at render time (dynamic pricing, live data)
• Query database (show related posts, filter by user)
• Use any npm package (charts, maps, 3D, animations)
• Personalize by user/location
• Integrate AI at render time

11. Internal Link Integrity

NOTED

Key advantage over WordPress.

WordPress stores internal links as raw URL strings. If you change a slug, links break. Payload stores links as relationship references (page ID):

12. File & Media Management

NOTED

All uploads → Payload API → GCP Cloud Storage (mcai-media bucket)
                  │
                  └→ Database record (filename, alt text, dimensions, thumbnails)

13. Local Development & Preview

PLANNED

Setup

Your laptop (localhost:3000)
├── Next.js dev server        ← hot reload
├── Payload CMS admin         ← localhost:3000/admin
├── Local PostgreSQL          ← dev content (safe to break)
└── Local file uploads        ← /media folder (dev only)

Complete Vibe Coding Flow

Step 1: Claude creates block .tsx file
        → Hot reload → see empty block instantly

Step 2: Claude creates seed script + runs on LOCAL DB
        → Page appears at localhost:3000/pricing with content

Step 3: You fine-tune in localhost:3000/admin
        → Live preview, adjust text/images

Step 4: Claude syncs: reads local DB → updates seed script
        → Seed script now matches your final edits
        → Commit to Git

Step 5: git push → GitHub Actions → deploys to Cloud Run

Step 6: Run seed on production → page appears live

Two Databases

Seed Scripts (Content as Code)

Seed scripts in Git capture initial page content. Idempotent (safe to run multiple times):

Git repo
├── src/blocks/PricingBlock.tsx    ← design (code)
├── src/seed/pricing-page.ts       ← content (code)
└── src/seed/assets/               ← seed images

After initial creation, ongoing content edits happen directly in production /admin.

14. Git, CI/CD & Deployment

PLANNED

GitHub Repository: mcai-web

What Goes to GitHub vs What Doesn’t

GitHub Actions Auto-Deploy

On git push to main:

1. Build Docker image
2. Push to GCP Artifact Registry (mcai-registry)
3. Deploy to Cloud Run (mcai-web)

GitHub Secrets

Day-to-Day Development Process

Future Updates & Maintenance

15. Vibe Coding Workflow

NOTED

Three Channels, Each Handles Its Own Concern

Day-to-Day After Setup

90% of daily work = /admin panel. Only new designs need Claude Code.

16. 3-Layer Guardrails

PLANNED

17. Migration Phases

PLANNED

Phase 0: Trial on site.mcai.dev ACTIVE

• Build new site on separate domain
• No risk to production
• Learn the stack, build blocks, test admin panel
• Recreate a few pages to validate approach

Phase 1: Set Up Production Infrastructure

• Set up Cloud SQL, Cloud Storage, Cloud Run on GCP
• Configure GitHub Actions auto-deploy
• Define all Payload collections
• Build header/footer/nav matching current brand
• Install Payload plugins

Phase 2: Configure Domain Routing

• Set up Cloudflare Worker for masterconcept.ai
• Route /blog/* to WordPress, everything else to Cloud Run
• Test cross-linking between systems
• A record unchanged, just Worker route added

Phase 3: Migrate Landing Pages (One by One)

• Screenshot → screenshot-to-code → React/Tailwind blocks
• Upload images via Payload API
• Create page in admin, same slug
• Monitor SEO per page (see SEO Safety)
• Migrate HubSpot form pages, ebook/download pages

Phase 4: Migrate Blog (Optional - When Ready)

• Export WordPress posts via REST API
• Import into Payload Posts collection
• Marketing team switches to /admin
• Remove WordPress proxy rules
• Downgrade/cancel SiteGround

Phase 5: Cleanup & Optimization

• Performance testing
• SEO verification (meta, structured data, sitemaps, redirects)
• Configure user roles
• Set up version history retention

18. SEO Safety

PLANNED

What Google Cares About

Page-by-Page Migration (No Big Bang)

Move ONE page → monitor 2 weeks → rankings stable? → move next page

If any page drops: investigate, fix, or rollback that single page (WordPress still running).

Per-Page Checklist

Before: Record rankings, impressions, clicks
After:  Verify URL, content, meta, images, structured data, speed
        Submit for re-indexing in GSC
        Monitor for 2 weeks

Performance Should IMPROVE

19. Converting Elementor Pages

NOTED

1. Screenshot-to-code - AI generates React/Tailwind from screenshots
2. Images - upload to Payload Media → GCP Cloud Storage
3. Header/Footer - rebuild once, match current brand (same logo, colors, fonts, nav)
4. Popups - rebuild as React modal components
5. HubSpot forms - embed via HubSpotFormBlock
6. Ebooks/downloads - upload to Payload Media
7. html-widgets/ - convert existing HTML widgets to Payload block components

Style Consistency During Transition

Blog (WordPress) and landing pages (Next.js) can coexist on same domain. Keep same header/footer/nav/brand colors/fonts = visitors won’t notice. Landing pages already look different from blog posts on most sites.

20. Cross-Linking Blog & Landing Pages

PLANNED

21. HubSpot Integration

NOTED

22. AI-Automated SEO

NOTED

23. WebMCP Readiness

NOTED

WebMCP (W3C Draft, Feb 2026) lets websites expose capabilities to AI agents in the browser. Different from regular MCP - runs client-side via navigator.modelContext.

• Status: Chrome 146 Canary early preview, cross-browser ~late 2027
• Works on ANY website (WordPress or Next.js) - not a migration reason
• Next.js has webmcp-next plugin for easier integration
• Can add to WordPress too via HTML toolname attributes or JS API

When ready, Payload APIs can be exposed as WebMCP tools for AI agents to create/update pages, upload media, run SEO audits.

24. Future Enhancements

NOTED

• WebMCP server when protocol matures
• AI SEO automation (scheduled audits)
• Full blog migration from WordPress to Payload
• Cancel SiteGround after full migration
• Multi-language via Payload’s built-in localization
• AI content generation via Payload API

25. Reference URLs

• Payload CMS demo: https://demo.payloadcms.com/admin/login
• Payload CMS docs: https://payloadcms.com/docs
• Payload vs WordPress: https://payloadcms.com/compare/wordpress
• Payload website template: https://github.com/payloadcms/template-website
• Payload plugins: https://payloadcms.com/docs/plugins/overview
• screenshot-to-code: https://github.com/abi/screenshot-to-code
• shadcn/ui: https://ui.shadcn.com
• GCS Storage plugin: https://payloadcms.com/docs/plugins/cloud-storage
• Cloud Run docs: https://cloud.google.com/run/docs
• GitHub Actions + Cloud Run: https://cloud.google.com/run/docs/continuous-deployment-with-cloud-build