Accounts, API, MCP, DNS, and Secrets
Use this before the website build prompt. The goal is simple: know which accounts the owner controls, which tools an agent can use safely, which steps must happen in a browser, and which Site Clinic capabilities require entitlement.
Minimum setup for a new website
Know where the domain lives, usually GoDaddy or another registrar. The owner keeps the login and makes DNS changes in the browser when exact records are ready.
Choose who owns the repository. Codex or a developer can work inside it, but the business should control the long-term account or organization.
Use Vercel as the default when possible, or document the client-required platform such as WordPress, Shopify, ASP.NET/IIS, static hosting, or a custom server. The owner controls billing, domains, and production approval.
Prepare the Google account that will own search and analytics data. Codex can add tags or files, but the owner verifies access and submits the sitemap.
Use Site Clinic for the monitoring and proof layer after the site has a live URL. API, MCP, scheduler, Blog Writer, and managed workflows require entitlement.
Who does what
Codex can create branches, edit files, commit, and push when the repo is available and GitHub access is approved. The human owner should create or approve the account and repo ownership.
A coding agent can prepare deploy settings and run host commands when authenticated. Some platforms remain manual or client-controlled. The human owner approves project ownership, billing, domains, and production cutover.
Treat GoDaddy DNS as a browser step for novice onboarding. Codex should provide exact records, but the owner logs into GoDaddy and applies them.
Stripe keys and webhooks can be wired by an agent only after the owner creates or approves the Stripe account. Never paste secret keys into public files or chat logs.
Codex can add verification files, tags, and analytics snippets. The human owner verifies properties, submits sitemaps, confirms access in Google, and grants Site Clinic the connector access needed for private dashboard data.
The Site Clinic API is the programmatic layer for scans, usage, reporting, and evidence workflows. API keys belong in local or hosted secret storage, never in public code.
MCP is the agent-facing tool layer. Use it when Codex, Claude Code, Cowork, or another MCP-capable assistant needs confirmed Site Clinic tools such as crawler or scheduler operations instead of hand-written API calls.
Blog Writer is a scheduler-owned Site Clinic content pipeline. Treat it as an entitled automation workflow, not as a direct MCP tool unless a specific MCP tool is configured and documented.
Where Site Clinic API, MCP, scheduler, and Blog Writer fit
A basic website build can finish without API or MCP. The first job is ownership, files, deployment, DNS, Search Console, GA4, and Site Clinic monitoring.
API access is for software and workflows that need authenticated Site Clinic data. MCP access is for agent clients that need supported Site Clinic tools available inside the coding or operations assistant.
MCP becomes useful when the agent should ask Site Clinic for evidence, trigger supported crawler checks, inspect proof runs, work through monitored-site context, or operate scheduler-owned workflows.
The Blog Writer pipeline is an advanced Site Clinic workflow owned by the scheduler. A site should not be put on recurring content production until the site, keyword/source files, image policy, publish target, schedule ownership, and Site Monitor reporting are all configured.
The safe rule is: website ownership and DNS stay human-controlled; repo and deploy work can be delegated to Codex when authenticated; Site Clinic API/MCP access gives the agent the evidence and workflow layer, but only after keys and scope are deliberately set.
Use API keys for backend jobs, dashboards, customer workflows, webhooks, reporting, or scheduled checks.
Use MCP when a coding assistant should call confirmed crawler, scheduler, proof, monitoring, or remediation capabilities directly as tools.
Use the scheduler for recurring checks, Blog Writer publishing, proof runs, and other cadence-owned workflows. Do not create repo-local timers when Site Clinic owns the cadence.
Use crawler capabilities for crawlability, SEO, accessibility, indexing, content, and technical proof signals that should feed Site Monitor.
Use Blog Writer only after the site has its project folder, keyword clusters, image handling, publishing target, scheduler ownership, and monitoring contract ready.
DNS changes, billing approvals, domain ownership, and Google account verification stay browser-led by the owner.
Connecting Search Console and GA4 after Pro checkout
A Pro customer with an existing site should not be blocked from checkout by private Google setup. Checkout captures the email and canonical site URL, then Site Clinic provisions the baseline dashboard from public evidence.
Search Console and GA4 are the next owner-granted connector step. The site owner identifies the Search Console property, the GA4 property or measurement ID, and the Google account that can approve access. Site Clinic then joins those sources into the existing dashboard.
Until connected, the dashboard should show those sections as pending credentials, not as fake zero traffic. Once connected, Search Console powers query, page, impression, position, and CTR context; GA4 powers engagement, page, referral, and conversion context.
Enter the canonical website URL at checkout. Public monitoring starts from that URL before private Google data exists.
Confirm the Search Console domain or URL-prefix property and the GA4 property that belong to the monitored site.
The owner grants Site Clinic connector access, or a developer supplies the exact property IDs, verification method, and access path.
Site Monitor should show connected state and fresh data before recommendations rely on Search Console or GA4 signals.
Entitlements and paywall boundary
Public docs can explain the setup path, but operational access is not public. API keys, MCP tool use, scheduler-owned automation, Blog Writer runs, and private Site Monitor dashboards should require an authenticated Site Clinic account with the correct trial, paid plan, or managed-service entitlement.
Site Monitor is the evidence dashboard and should reflect only the capabilities enabled for that account or site. If an account is not entitled to API, MCP, scheduler, Blog Writer, or client dashboard access, the UI should show setup guidance or upgrade/contact steps instead of executable controls.
Blog Writer is especially sensitive because it can publish content. Treat it as a paid or explicitly approved workflow with per-site configuration, proof artifacts, image requirements, governance checks, and Site Monitor visibility before any recurring run is considered active.
Cancellation should disable future operation, not rewrite history. Previously delivered customer-owned files, public pages, domains, and exported proof artifacts are not revoked; future dashboard access, scans, automation, API/MCP calls, Blog Writer runs, and managed reporting are.
Public pages may teach setup, DNS, account preparation, launch checklists, and what evidence Site Clinic will verify.
API keys and MCP-capable tool access require a Site Clinic account, scoped credentials, plan limits, and revocation/rotation controls.
Recurring checks, Blog Writer publishing, proof runs, and managed client workflows require explicit account/site entitlement and Site Monitor reporting.
Client-facing dashboards should show only the sites, workflows, runs, proofs, and recommendations the account is allowed to access.
Customer-owned website code, domain records, and public pages already delivered remain portable even when the paid operating layer is cancelled.
Recurring scans, alerts, connected-data sync, API/MCP access, scheduler execution, Blog Writer, dashboards, and future proof output are controlled by entitlement.
Blog Writer MCP direction
The current Blog Writer truth is scheduler-owned automation with repo-owned publishing and proof verification. It should not be exposed as a blind publish button.
The correct future MCP shape is an internal content-operations surface: list sites, inspect site context, read keyword queues, check readiness, validate drafts, list proofs, dispatch an approved publisher workflow, and verify the live result.
Start read-only and dry-run first. Write or dispatch tools should require explicit entitlement, operator confirmation, correlated proof, and live URL verification before Site Monitor records success.
Expose read-only tools for site context, keyword queues, readiness, governance gates, and existing publish proofs before enabling execution.
When enabled, MCP should dispatch the reliable repo-owned publisher workflow and require proof correlation plus live URL verification.
Do not let an agent write directly to production blog content without queue state, governance checks, entitlement, proof artifacts, and Site Monitor reporting.
DNS path for a new GoDaddy domain
Do not change DNS first. Build or deploy the site first, then use the host's exact domain instructions. For Vercel, this usually means adding the domain in Vercel, then applying either nameservers or DNS records in GoDaddy. For WordPress, Shopify, ASP.NET/IIS, or another platform, use that host's exact records instead.
For an apex domain, the host may ask for an A record. For a www subdomain, the host may ask for a CNAME. For verification, the host or Google may ask for a TXT record. The owner should copy the values exactly and wait for propagation.
The safe novice rule is simple: Codex writes the record list and verification checklist; the domain owner changes GoDaddy in the browser; Site Clinic verifies the live result after propagation.
Let Vercel, WordPress, Shopify, IIS hosting, or the selected platform tell you the exact records or nameservers it expects. Do not guess DNS values from an old checklist.
The domain owner logs in, copies the exact records, saves the change, and waits for DNS propagation.
After propagation, verify apex, www, https, redirects, sitemap, robots, and Site Clinic monitoring before calling the launch complete.
Secrets and tokens
Use OAuth, CLI login, scoped API keys, or environment variables. Passwords and recovery codes stay with the account owner.
Give the agent or developer only the access needed for the task: repo, deployment project, test Stripe key, or Site Clinic API key.
Store secrets in .env.local, Vercel environment variables, or the approved secret manager. Never commit live keys.
When a contractor, agent, or temporary workflow is done, rotate keys and remove access that is no longer needed.
Copy-paste account setup prompt
Use this prompt before the website build prompt when the customer is new to GitHub, Vercel, DNS, or analytics setup.
You are helping me prepare accounts, API access, DNS, deployment, and secrets for a Site Clinic website build. Goal: Get the project ready for an AI coding agent or developer without exposing passwords, confusing account ownership, or changing DNS too early. My current status: - Domain registrar: [GoDaddy / other] - Domain name: - GitHub account exists: [yes / no] - GitHub repo exists: [yes / no] - Vercel account exists: [yes / no] - Required deployment stack: [none / Vercel / WordPress / Shopify / ASP.NET/IIS / static host / custom server / other] - Site Clinic account exists: [yes / no] - Site Clinic API key exists: [yes / no / not needed yet] - Site Clinic MCP access needed: [yes / no / not sure] - Site Clinic MCP capabilities needed: [crawler / scheduler / not sure] - Scheduler-owned workflows needed: [blog writer pipeline / proof runs / recurring checks / not sure] - Stripe/payment account needed: [yes / no] - Google Search Console property exists: [yes / no] - GA4 property exists: [yes / no] - Local project folder exists: [yes / no] Rules: 1. Never ask me to paste account passwords. 2. Tell me which steps Codex can do with a token and which steps I must do in a browser. 3. Treat GoDaddy DNS as a manual browser step unless I explicitly say API access is available. 4. Explain whether I need Site Clinic API, Site Clinic MCP, both, or neither for this phase. If MCP is needed, say whether this is crawler, scheduler, or another confirmed supported capability. If recurring content is needed, treat Blog Writer as a scheduler-owned Site Clinic pipeline unless a direct MCP tool is explicitly configured. 5. Do not change DNS until the selected deployment target is ready and the required records are known. 6. Store tokens only in the approved local environment or hosting secret manager. 7. End with a checklist showing: GitHub ready, project folder ready, deployment ready, DNS action ready, Search Console/GA4 ready, Site Clinic API/MCP ready if needed, scheduler-owned workflows ready if needed, Site Clinic monitoring ready. If you are Codex: Inspect the repo if one exists, tell me exactly which external account actions are needed, then continue after I confirm those are complete.