Follow the actual call sequence.
Altansukh said the website is the first thing he wants to move. Shanee’s advice was not to begin with a big redesign theory or DNS work. The path is practical: examples, rules, buyer language, keyword strategy, GitHub, Cloudflare preview, Agent Ready score, then GoDaddy/DNS after safety checks.
Get examples of websites Altansukh likes.
Turn those examples into design rules.
Fix the buyer language so the site does not make prospects feel exposed.
Build the keyword SEO strategy before Codex writes the pages.
Create the GitHub repository before the website build starts.
Tell Codex or Claude Code to rebuild the current content inside that repo.
Use Chrome Use or Computer Use to connect GitHub to Cloudflare Pages and create a dev preview link.
Run the dev preview through Is It Agent Ready and fix what matters.
Only after the dev link is verified, prepare Cloudflare DNS and GoDaddy cutover.
Do not start by moving DNS.
The live domain should not move from GoDaddy to Cloudflare until the new site preview works, DNS records are documented, Microsoft email records are documented, forms and booking links are understood, important URLs are inventoried, Cloudflare DNS records match the current DNS inventory, and a rollback owner is named.
Email matters more than website polish. If email breaks, stop and fix DNS/email first.
Claude means Claude Code.
When Shanee said Claude, she meant Claude Code, not Claude chat and not Claude Cowork. The website work should happen in Codex or Claude Code inside a real GitHub-connected repository.
Chat-only tools may help think through design, but they are not the operating system for the website.
Keep the build docs one click away.
One useful piece from the Claude guide was a practical reference table. These are the docs Nandir or the developer will likely need during the GitHub, Cloudflare, Astro, GoDaddy, and Microsoft email parts of the launch.
| Topic | Link |
|---|---|
| Cloudflare Pages overview | developers.cloudflare.com/pages/ |
| Cloudflare Pages framework guides | /pages/framework-guides/ |
| Connect GitHub to Cloudflare Pages | /pages/get-started/git-integration/ |
| Cloudflare Pages custom domains | /pages/configuration/custom-domains/ |
| Cloudflare DNS full setup | /dns/zone-setups/full-setup/ |
| Cloudflare nameserver setup | /dns/zone-setups/full-setup/setup/ |
| Astro docs | docs.astro.build |
| Astro on Cloudflare Pages | Deploy an Astro site |
| GitHub repo quickstart | GitHub quickstart |
| GoDaddy nameserver change | GoDaddy help article |
| Microsoft 365 DNS records | Microsoft DNS records |
| DMARC overview | dmarc.org/overview/ |
| Codex | github.com/openai/codex |
| Claude Code | Claude Code docs |
Use one source of truth.
Another strong part of Claude’s guide was the simple system map: GitHub holds the website truth, Cloudflare hosts what GitHub holds, and GoDaddy only points nameservers to Cloudflare after launch gates pass.
Codex or Claude Code edits the GitHub repo.
GitHub holds branches, pull requests, content, design rules, redirects, and launch docs.
Cloudflare Pages builds previews and production from GitHub.
Cloudflare DNS holds website, email, and verification records after cutover.
GoDaddy remains the registrar, then points nameservers to Cloudflare after approval.
Notion or Google Drive can support human review, but neither becomes the live website source.
Collect the launch facts before asking Codex to build.
The migration packet from Claude’s guide is useful because it keeps the project from becoming a guessing exercise. Put these items in a folder called Website Migration Packet before the build starts.
Collect
- Current website URL and current host / CMS / vendor name.
- GoDaddy login owner, without sharing passwords in chat.
- Current DNS records exported or screenshotted.
- Microsoft email records: MX, SPF, DKIM, DMARC.
- Contact forms, form destinations, and booking links.
- Important service pages and resource pages.
Also Collect
- Analytics and Search Console access status.
- Top 3-5 design inspiration websites.
- Logo, colors, fonts, and key images.
- Approved vs. unapproved customer logos, testimonials, and case studies.
- Buyer language: what buyers call the urgent problem and what language they avoid.
Stop Point
Do not move nameservers if MX, SPF, DKIM, and DMARC records are not documented.
Decide what Codex is building before it builds.
Purpose
Altansukh needs to decide whether the team is copying the current design or creating a better design using the current content.
Framework
- Use the current website content as the starting point.
- Do not keep the current vendor CMS.
- Do not copy the generic cloud-template look.
- Create a cleaner design based on examples Altansukh likes.
Answer First
- What is the current website URL?
- What are 3-5 websites Altansukh likes visually?
- What does he like about them: spacing, typography, hero section, navigation, colors, page flow?
- What content from the current site should stay?
- What content needs rewriting?
- What is the main buyer action: book a call, request a diagnostic, contact sales, or download something?
We are rebuilding the MVP1st website. Context from Shanee and Altansukh's call: - The current site is in an MSP Science / GoHighLevel-style vendor setup. - The domain is in GoDaddy. - We want to move to GitHub + Cloudflare Pages. - We want to use the current website content as the starting point. - We do not want to copy the generic vendor template. - We want a better design based on examples Altansukh likes. First, help me define the website direction. Ask me for: - current website URL - 3-5 inspiration websites - what I like about those websites - what pages/content must stay - what pages/content should be rewritten - the main buyer action for the site Do not build yet. Do not deploy anything. Do not change DNS.
Stop Point
Do not build if Altansukh has not provided either design examples or a clear direction.
Done When
Current URL is known, inspiration sites are collected, main buyer action is chosen, and the team agrees whether this is a redesign or content migration with light styling.
Replace “make it look good” with usable design rules.
Shanee advised that the easiest way to get a better website is to show the agent what Altansukh likes, then make the agent define rules around that design.
Rules Should Cover
- H1 size and style
- H2 size and style
- Body copy style
- Spacing and section rhythm
- Navigation and hero structure
- Buttons, cards, images, mobile behavior
- What to avoid
Study these inspiration websites: [URL 1] [URL 2] [URL 3] [URL 4] [URL 5] Do not copy them. Extract practical design rules for the MVP1st website: - H1 typography - H2 typography - body text - spacing - section rhythm - navigation - hero section structure - button style - card style - image style - color use - mobile behavior - what to avoid Write these rules into DESIGN_SYSTEM.md. The site should feel like an enterprise AI / Microsoft Dynamics / business systems implementation company. It should not feel like a generic SaaS template or generic cloud-services template.
Stop Point
Do not ask Codex to build the site until DESIGN_SYSTEM.md exists.
Done When
Design examples have been reviewed, DESIGN_SYSTEM.md exists, and the team can describe the intended design in plain language.
Do not make buyers feel like they are admitting failure.
Altansukh said that when people hear ERP, many shut down. He also said that ERP rescue can make buyers feel exposed.
Use Caution With
- ERP rescue
- ERP failure
- Failed ERP implementation
- Broken ERP
- Technical customization
- Complex ERP remediation
Better Frames To Test
- AI-enabled ERP modernization
- Microsoft Dynamics modernization
- Business system implementation
- Enterprise workflow automation
- Operational transformation
- Business systems that teams can actually run
Create a buyer language guide for the MVP1st website. Context: - Altansukh said buyers shut down when they hear ERP too directly. - He also said "ERP rescue" can make customers feel embarrassed or exposed. - We need better framing for the website. Create a section in CONTENT_MODEL.md called Buyer Language Rules. Include: - language to avoid - safer buyer-facing language to test - homepage positioning options - service page positioning options - phrases that explain the work without blaming the buyer Do not invent customer examples. Do not invent claims. Do not publish this as final copy without human review.
Stop Point
Do not write final homepage copy if the language still sounds like ERP rescue or makes the customer feel exposed.
Done When
Buyer language rules exist, better positioning options are drafted, and Altansukh can review the language before launch.
Use the current site as content source, not operating model.
Shanee advised using the current site information as the content base. Codex needs to inspect the current site and decide what to keep, rewrite, redirect, or review.
| Status | Meaning |
|---|---|
| Keep | Useful and should remain mostly intact. |
| Rewrite | Topic matters, but copy or positioning needs improvement. |
| Redirect | Old URL should point to a better new URL. |
| Delete | Only with approval. |
| Unsure | Needs human review. |
Inventory the current website at [CURRENT WEBSITE URL]. Use the current site content as the starting source for the new website. Do not copy the old CMS structure. Do not assume the old design is the right design. Create docs/current-site-inventory.md with: - all visible pages and URLs - page title for each important page - meta description for each important page - H1 for each important page - forms and where they appear - visible form behavior, without submitting forms - booking links - resource or insight pages - landing pages - download or lead magnet pages - tracking scripts or pixels visible in page source - important images and files - URLs that should be preserved or redirected Mark every page as: - Keep - Rewrite - Redirect - Delete - Unsure Do not submit forms. Do not copy private data. Do not deploy anything. Do not delete anything.
Stop Point
Do not delete or redirect any page that may have SEO, ad, sales, referral, customer support, or historical value.
Done When
All important pages are listed, forms and booking links are documented, redirect candidates are identified, and unknown pages are marked Unsure.
Choose the search strategy before Codex writes pages.
Altansukh does not need a generic website with generic ERP language. He needs a site that can be found for the right searches, understood by the right buyers, and visible in AI-assisted search without making prospects feel blamed or exposed.
Purpose
Turn the buyer language into a practical SEO and AI-search strategy before the homepage and service pages are written.
Strategy Should Define
- Primary category phrase
- Buyer-safe language to use
- Language to avoid
- Service keyword clusters
- Page-to-keyword map
- FAQ/search questions
- AI visibility phrases
Create docs/keyword-seo-strategy.md for the MVP1st website. Context from Shanee and Altansukh: - Altansukh said buyers shut down when ERP language is too direct. - "ERP rescue" can make buyers feel embarrassed or exposed. - The website needs search visibility and AI-search visibility, but the language still has to feel safe for the buyer. - We need to identify the right category before writing the main pages. Build a keyword strategy with: - avoided terms - buyer-safe terms - primary category hypothesis - supporting service keyword clusters - homepage keyword focus - service page keyword focus - page-to-keyword map - FAQ/search questions buyers may ask - AI visibility phrases to test - content gaps from the current site inventory - terms that require human review Use the current website inventory and buyer language rules. Do not invent rankings. Do not invent search volume. Do not invent customer proof. Do not invent customer claims. Do not publish final page copy without human review.
Stop Point
Do not build service pages until the team has chosen the primary buyer-facing category and the most important keyword clusters.
Done When
docs/keyword-seo-strategy.md exists, the primary category hypothesis is chosen, the page-to-keyword map exists, and first SEO priorities are clear before the build starts.
Make GitHub the website source of truth.
GitHub should exist before Codex starts the actual website build. This is where code, page content, service content, design rules, and change history live. Notion can be the human interface. Google Drive can hold source files if needed. The website itself should live in GitHub.
Create the starter file structure for a GitHub-managed, Cloudflare Pages website. Repository name: mvp1st-website Include: - README.md - AGENTS.md - DESIGN_SYSTEM.md - CONTENT_MODEL.md - package.json - public/ - src/pages/ - src/components/ - functions/api/ - docs/current-site-inventory.md - docs/keyword-seo-strategy.md - docs/dns-inventory.md - docs/redirect-map.md - docs/launch-checklist.md - .github/pull_request_template.md - .github/workflows/checks.yml Do not deploy anything yet. Do not ask for secrets. Do not push directly to production.
Stop Point
Do not continue if developers are working from private local folders as the real source of truth. Do not let Codex build the real website in a random scratch folder first and then try to move it later.
Done When
Private GitHub repo exists, starter structure exists, first commit is pushed, and everyone understands GitHub is the source of truth.
Prevent hidden work across people and agents.
Shanee warned that if one agent publishes content and another agent cannot see it, the operating system breaks. Codex, Claude Code, and developers need the same rules.
Create README.md, AGENTS.md, and CONTENT_MODEL.md for this website repo. Rules: - GitHub is the source of truth. - Every meaningful change should happen on a branch. - Run the build before finalizing. - Do not ask for passwords or secrets. - Do not commit secrets. - Do not push directly to main unless explicitly approved. - Do not move DNS before preview QA. - Do not invent customer proof, testimonials, logos, metrics, case studies, revenue claims, or security claims. - Do not change forms, tracking, DNS, redirects, pricing, offers, production settings, canonical URLs, or robots.txt without human approval. - All meaningful website updates must be visible in GitHub. README.md should explain the website purpose and deployment model. AGENTS.md should explain source of truth, workflow, review gates, and safe-change rules. CONTENT_MODEL.md should define page types, service page fields, FAQ fields, case study draft fields, and proof rules.
Stop Point
Do not let agents publish public copy until no-invention and approval rules are documented.
Done When
README, AGENTS.md, and CONTENT_MODEL.md exist, and human approval rules are clear.
Get content and structure working before polish.
Shanee told Altansukh not to get upset if the first design is not perfect. First make sure content and structure are right. Design can be refined after the first preview exists. This work should happen inside the mvp1st-website GitHub repo, on a branch, not in a separate untracked local folder.
Build the first version of the MVP1st website as a static-first Cloudflare Pages site. Use Astro unless there is a strong reason to choose another Cloudflare-compatible framework. Read: - README.md - AGENTS.md - DESIGN_SYSTEM.md - CONTENT_MODEL.md - docs/current-site-inventory.md - docs/keyword-seo-strategy.md - docs/redirect-map.md Build: - homepage - services overview page - individual service pages if needed - about page - contact or diagnostic page - 404 page - robots.txt - sitemap if supported by the framework Requirements: - Cloudflare Pages compatible - static-first - fast build - mobile responsive - SEO title and meta description for every page - preserve or redirect important existing URLs - no fake testimonials - no fake customer logos - no invented metrics - no invented case studies - no invented client names - no production deploy yet After building: - run the build - show the build command - show the output directory - show how to preview locally
Stop Point
Stop if build fails, local preview does not load, fake proof appears, important URLs are missing, or forms are unclear.
Done When
Local preview loads, build passes, core pages exist, mobile works, no fake proof is visible, and important URLs are preserved or mapped.
Do not fight one small visual issue at a time.
Make the preview bigger, scroll through it, start the microphone, and give one 3-5 minute batch of feedback. Codex is strong at applying a specific batch.
I am reviewing the local preview in one pass. Apply the following changes as one batch: 1. [change] 2. [change] 3. [change] 4. [change] 5. [change] Do not change unrelated sections. Do not invent new proof. Do not change the page strategy unless I ask for it. Run the build again after edits. Summarize what changed.
Stop Point
Stop if feedback reveals the message is wrong. Fix content and structure before visual polish.
Done When
First feedback batch is applied, build still passes, and preview is good enough to show externally.
Make the work durable and reviewable.
Prepare this initial website build for GitHub review. Use a branch named: initial-site-build Open a pull request into main. The pull request should include: - summary of what changed - pages created - build command used - output directory - known issues - items needing human review - confirmation that no secrets were committed - confirmation that no fake proof was added - confirmation that DNS was not changed - confirmation that production was not changed Do not push directly to main unless explicitly approved. Do not deploy production. Do not change DNS.
Stop Point
Stop if secrets, fake proof, unapproved claims, DNS changes, or production changes appear in the diff.
Done When
Branch is pushed, pull request is open, build check passes, and work is visible in GitHub.
Create the dev preview link before touching the main domain.
This is where Codex should use browser control if Altansukh or Nandir wants help with the Cloudflare UI. The goal is not to launch the main domain yet. The goal is to connect the GitHub repo to Cloudflare Pages and get a temporary pages.dev preview URL working first.
Browser Automation Rule
Codex can use Chrome Use or Computer Use to operate the browser for GitHub and Cloudflare setup. That means it can click through Cloudflare Pages, select the GitHub repo, enter build settings, and start the preview deploy. It should not paste secrets into chat and should not connect the live domain at this stage.
| Framework | Build Command | Output Directory |
|---|---|---|
| Astro | npm run build | dist |
| Vite / React | npm run build | dist |
| Static HTML | exit 0 | public |
Use Chrome Use or Computer Use to help connect the GitHub repository to Cloudflare Pages. Use the GitHub repository as the source. Goal: - create a Cloudflare Pages project - connect it to the GitHub repo - deploy a temporary pages.dev preview link - verify the preview works before the main domain is touched Cloudflare Pages settings: - framework: [Astro / Vite / Static HTML] - build command: [npm run build / exit 0] - output directory: [dist / public] - production branch: main Browser steps: 1. Open Cloudflare. 2. Go to Workers & Pages. 3. Create a Pages project. 4. Connect GitHub. 5. Select the mvp1st-website repository. 6. Confirm the branch and build settings. 7. Deploy to the Cloudflare pages.dev URL. 8. Open the pages.dev URL and verify the homepage and main pages load. Do not connect the live domain yet. Do not move nameservers. Do not change production DNS. Do not paste passwords or tokens into chat. After this step, report: - Cloudflare Pages project name - pages.dev preview URL - build command - output directory - whether preview loaded - issues that need fixing before domain setup
Preview QA Checklist
- Homepage, services, about, and contact or diagnostic pages load.
- Navigation and mobile menu work.
- Contact buttons go to the right place.
- Forms are disabled, clearly marked, or correctly wired.
- Booking links work.
- Sitemap, robots.txt, and 404 page exist.
- Important existing URLs have a preserve or redirect plan.
- Page titles and meta descriptions exist.
- No fake testimonials, logos, metrics, or claims are visible.
- No accidental noindex exists on production-intended pages.
Stop Point
Do not continue if the preview does not load. Do not connect the live domain if lead capture does not work or important redirects are missing.
Done When
Cloudflare gives a pages.dev preview URL, homepage loads, main pages load, mobile works, and the live domain has not changed.
Score the dev preview before the real domain goes live.
Once the design is ready and the Cloudflare dev preview works, Altansukh should run the pages.dev preview through isitagentready.com. This keeps the launch focused on a site that is clear, crawlable, structured, and useful for AI-assisted discovery, not just a site that looks finished.
Important Order
Use the Cloudflare pages.dev preview URL first. Do not wait until the main domain is live to find the Agent Ready issues.
Use Chrome Use or Computer Use to open https://isitagentready.com. Test the Cloudflare pages.dev preview URL before the main domain is connected. Goal: - get the Agent Ready score - identify missing or weak items - turn the findings into specific website fixes - apply approved fixes in the GitHub repo - run the build again - redeploy the Cloudflare Pages preview - retest the pages.dev URL Do not test the live domain first. Do not change DNS. Do not invent claims or proof to improve the score. After checking the score, create a short remediation list: - issue - affected page or file - recommended prompt for Codex - whether human approval is needed - status
Review the Agent Ready findings for the MVP1st pages.dev preview. Create a branch and fix the issues that are safe to fix: - missing or weak metadata - unclear page structure - weak headings - missing sitemap - missing robots.txt - missing structured page summaries - missing internal links - unclear service descriptions - weak buyer-facing language - missing alt text Do not invent testimonials, metrics, case studies, customer names, security claims, or revenue claims. Do not change DNS, forms, tracking, pricing, offers, canonical URLs, or robots.txt crawl rules without approval. Run the build after edits. Summarize what changed. Redeploy the Cloudflare Pages preview and retest the pages.dev URL.
Stop Point
Do not connect the main domain until the Agent Ready findings are fixed or explicitly accepted as launch exceptions.
Done When
The pages.dev preview has been tested, score and findings are documented, safe fixes are applied, build passes again, and the preview is retested before domain setup.
Put the safety gate where it belongs: before GoDaddy cutover.
Shanee’s call gave the high-level order: build, GitHub, Cloudflare, then GoDaddy to Cloudflare. Before that final GoDaddy step, document DNS and email.
Cloudflare DNS Zone Checklist
- Add the domain to Cloudflare.
- Let Cloudflare scan records.
- Compare every scanned record against
docs/dns-inventory.md. - Add missing records manually.
- Confirm Microsoft email records are present.
- Confirm verification records and subdomains are present.
- Confirm the DNSSEC plan.
- Do not change GoDaddy nameservers yet.
Create docs/dns-inventory.md and update docs/launch-checklist.md before any GoDaddy nameserver move. Context: - The domain is in GoDaddy. - Cloudflare will become the DNS/provider path. - Microsoft email must not break. Document: - current nameservers - A records - CNAME records - MX records - SPF record - DKIM records - DMARC record - Microsoft verification records - Search Console verification records - CRM or marketing verification records - subdomains - current redirects - DNSSEC status - rollback owner - email test owner Do not move nameservers. Do not proxy email records. Do not delete unknown records. Do not proceed if Microsoft email records are unclear. If using Chrome Use or Computer Use: - open Cloudflare DNS in the browser - open GoDaddy DNS in the browser if available - compare records visually against docs/dns-inventory.md - record mismatches in docs/launch-checklist.md - do not save DNS changes unless Altansukh has explicitly approved that exact change
Stop Point
Stop if MX, SPF, DKIM, DMARC, Microsoft verification records, or unknown subdomains are missing or unclear.
Done When
DNS inventory is complete, Microsoft email records are confirmed, rollback owner is named, and preview QA has passed.
Cut over only after preview and email safety pass.
This is the risky launch step. It requires Altansukh approval. Codex may use Chrome Use or Computer Use to operate Cloudflare and GoDaddy in the browser, but only after the dev pages.dev preview works and the DNS/email safety checklist is complete.
Do This On A Dev Link First
The correct order is GitHub repo → Cloudflare Pages project → pages.dev preview → preview QA → DNS/email inventory → custom domain/DNS setup → GoDaddy nameserver cutover. Do not connect the main domain as the first Cloudflare step.
Custom Domain Setup Before Nameservers
- Add the apex domain in Cloudflare Pages.
- Add the
wwwdomain in Cloudflare Pages. - Choose the canonical direction.
- Recommended default:
www -> apex. - Confirm Cloudflare creates or recommends the right DNS records.
- Do not change nameservers until Cloudflare shows the custom domain path is ready and DNS records are complete.
Use Chrome Use or Computer Use to help with the final Cloudflare and GoDaddy browser steps only after Altansukh approves the cutover. Prepare the final GoDaddy-to-Cloudflare cutover checklist. Do not perform the cutover unless Altansukh explicitly approves. Confirm: - Cloudflare pages.dev preview works - preview QA has passed - custom domain is configured - A / CNAME records are present - MX records are present - SPF is present - DKIM is present - DMARC is present - Microsoft verification records are present - other subdomains are present - redirect plan exists - forms are working or intentionally disabled - booking links work - rollback owner is named - email test owner is available - launch decision owner approves Browser steps after explicit approval: 1. Open Cloudflare Pages. 2. Open the mvp1st-website Pages project. 3. Add the custom domain: - apex domain: [DOMAIN] - www domain: [WWW DOMAIN] 4. Confirm Cloudflare's required DNS records. 5. Open Cloudflare DNS and verify website + Microsoft email records. 6. Open GoDaddy domain settings. 7. Copy Cloudflare's assigned nameservers. 8. Replace GoDaddy nameservers with Cloudflare nameservers. 9. Save only after approval is confirmed in the thread. 10. Wait for Cloudflare activation. After nameserver change, test: - apex domain - www - email receiving - email sending - contact form - booking links - Search Console ownership - analytics - important redirects - important subdomains If email breaks, stop website work and fix DNS/email immediately. After the browser work, report: - what changed - exact time nameservers were changed - Cloudflare activation status - email send/receive test result - live domain test result - form/booking test result - any rollback risk
Stop Point
Do not move nameservers without Altansukh approval, a rollback owner, and a Microsoft email test owner.
Done When
Live domain works, email sends and receives, forms and booking links work, important redirects work, and Cloudflare is active.
What Altansukh needs to decide.
- Current website URL
- 3-5 design inspiration websites
- Main buyer action for the site
- Buyer language to avoid
- Buyer language to test
- Primary SEO/category phrase to test
- Services that need dedicated pages
- Who owns GoDaddy access
- Who can confirm Microsoft email DNS records
- Who can approve the final domain cutover
- Who can approve public claims before launch
Final operating principle.
The practical order from Shanee’s advice is: design examples first, design rules second, buyer language and keyword strategy before page writing, GitHub repo created before the build starts, current content rebuilt inside that repo, Cloudflare dev preview before the main domain, Is It Agent Ready score before domain launch, and GoDaddy/DNS cutover only after safety checks.
Launch definition of done.
- GitHub is the source of truth.
- Cloudflare Pages preview works.
- Is It Agent Ready findings have been fixed or accepted as launch exceptions.
- Live domain works.
- Microsoft email still sends and receives.
- Contact or booking flow works.
- Important URLs are preserved or redirected.
- DNS inventory and launch checklist exist.
- Risky changes require approval.
- Codex or Claude Code can inspect, update, test, and open PRs without hidden local-only work.