Use the left sidebar to navigate between sections. Use the search bar at the top to find specific topics. The QA Checklist page is interactive — check off items as you complete them. All code blocks have a Copy button for easy use.
The System in One Table
Phase
Who
Tools
Time
Collect client brief
Onboarding Specialist
Brief template
1 hour
Build the site
Manus AI (directed by Specialist)
Manus
2–4 hours
Review & audit
Onboarding Specialist
W3C, WAVE, PageSpeed, AI Friendliness
1–2 hours
Launch
Onboarding Specialist
GitHub, Cloudflare Pages, Registrar
Under 1 hour
Add monitoring
Onboarding Specialist
UptimeRobot
5 minutes
Hand off to Quarterback
Onboarding Specialist
Go-live email template
15 minutes
Ongoing maintenance
Client Success Quarterback
Manus, GitHub, Cloudflare Pages
15–30 min/request
Escalation (if needed)
Tech Product Owner + contractor
Varies
As needed
Overview
The Philosophy
Why we are changing the model, and what we are building toward.
Why We Are Changing
The old website delivery model was built around human specialists: one person for project management, one for content, one for design, one for development, one for launch. Each handoff between specialists was a potential point of failure — a dropped ball, a miscommunication, a delay. The client experienced this as slow and inconsistent. Internally, it meant no single person owned the outcome.
AI tools have made the specialist model obsolete for the type of websites our trades company clients need. A well-prompted AI agent can produce a complete, high-performing, audit-passing website in hours. The human role shifts from doing the work to directing the AI, reviewing the output, and owning the client relationship.
The old model is not a people problem
This change is not about the quality of our current team. It is about the structure of the work. The specialist handoff model was the right design for a pre-AI world. It is the wrong design now. The goal is to redeploy talented people into roles where they own outcomes rather than tasks.
What We Are Building Toward
A system where one Onboarding Specialist takes a client from signed contract to live website without involving any other internal team member for routine builds. Client Success Quarterbacks handle all ongoing maintenance and content updates using AI tools, without needing a developer. The hosting infrastructure is fully managed — no servers to maintain, no SSL certificates to renew, no caching layers to configure.
The Five Non-Negotiable Outcomes
Every website we deliver passes four specific audits: W3C validation, WAVE WebAIM accessibility, PageSpeed Insights (100 on both mobile and desktop), and AI Friendliness.
One Onboarding Specialist runs the full build-to-launch workflow independently.
Client Success Quarterbacks handle all routine maintenance without developer involvement.
The hosting infrastructure is zero-maintenance — no servers, no SSL management, no caching fires.
The monthly cost of hosting and infrastructure per client site is near zero, preserving margin.
The key insight
In the old model, revenue scaled linearly with headcount. In this model, each Operator handles what used to require 3–4 specialists. Margins expand as we grow rather than compress. That is the business we are building.
The Stack
Tech Stack Overview
Every tool in the system — what it does, who uses it, and what it costs.
🤖
Manus AI
The Build Engine
Generates complete website code from a plain-English brief. Writes HTML, CSS, JS, copy, schema markup, sitemap, robots.txt, and llms.txt. Also handles ongoing content edits when directed by Quarterbacks.
Stores all website files for every client in a dedicated repository. Tracks every change ever made. Connects to Cloudflare Pages so updates deploy automatically within 60 seconds of a file change.
Onboarding SpecialistQuarterbacksFree
☁️
Cloudflare Pages
Hosting Platform
Hosts client websites on Cloudflare's global network. Issues and renews SSL automatically — forever. No server management. No caching configuration. Rebuilds and redeploys automatically when GitHub files update.
Onboarding SpecialistTech Product OwnerFree tier
🌐
Cloudflare Registrar
Domain Management
Registers and renews domain names at wholesale cost (no markup). Manages DNS in the same dashboard as Cloudflare Pages — connecting a domain to a site is a single click. Auto-renewal prevents accidental expiry.
Onboarding Specialist$8–$12/year per domain
📡
UptimeRobot
Passive Site Monitoring
Pings every client site every 5 minutes and sends an alert if a site goes down. Runs entirely in the background — no day-to-day attention required. Day-to-day responsibility: none.
Handles contact form submissions on static HTML sites without a server. When a visitor submits a form, Formspree receives it and forwards it to the client's email. No server-side code required.
Onboarding SpecialistFree / ~$10/mo agency
📝
Decap CMS
Optional Client Editing (Free)
Open-source, completely free CMS that sits on top of static HTML files. Used only when a client specifically requests self-editing access. Gives clients a simple browser-based editor to update text and images. No monthly fee — ever. For most clients, Quarterbacks handle edits via Manus instead.
QuarterbacksOnboarding SpecialistFree — open source
What goes away completely
Self-managed VPS servers (Cloudflare VPS, HostGator VPS) — cancelled. ManageWP — not needed. SSL certificate management — handled automatically forever. Server crashes — structurally impossible on Cloudflare Pages. The dependency on the head developer for infrastructure fires — eliminated.
How the Stack Connects
The flow is linear and automatic: Manus builds the site files → Onboarding Specialist uploads files to GitHub → GitHub triggers Cloudflare Pages to deploy → Cloudflare Pages serves the site to visitors with automatic SSL. When a Quarterback makes an update, the same flow repeats automatically. No manual deployment step. No server to touch. No SSL to renew.
The Stack
Audit Standards
Every site must pass all four audits before it goes live. No exceptions.
Non-negotiable standard
A site that does not pass all four audits is not ready to launch. If an audit fails, prompt Manus to fix the specific issue and re-run the audit. Do not launch until all four pass.
Validates that the HTML code follows web standards. Catches structural errors, missing attributes, and deprecated elements that can cause rendering issues across browsers.
Tests whether the site is usable by people with disabilities. Checks for missing alt text, poor color contrast, missing form labels, improper heading structure, and keyboard navigation issues.
Measures how fast the site loads on real devices. Checks Core Web Vitals including Largest Contentful Paint, Cumulative Layout Shift, and Interaction to Next Paint. Run on the live URL, not a staging URL.
Checks whether the site communicates effectively with AI systems and search engines. Looks for llms.txt, JSON-LD schema markup, sitemap.xml, robots.txt, and structured business information.
Pass
Why Plain HTML Makes These Achievable
The static HTML + Cloudflare Pages architecture is the only approach that makes all four audits achievable consistently and by default. WordPress makes PageSpeed 100 a constant battle — plugins, themes, and database queries all add weight. React and Vue frameworks render in the browser using JavaScript, which delays content appearance and tanks mobile PageSpeed scores.
On a plain HTML site built by Manus and hosted on Cloudflare Pages, PageSpeed 100 is the starting point, not something to fight for. The HTML is valid by construction. Accessibility is built into the prompt requirements. AI Friendliness files are generated automatically. The architecture works with the audits, not against them.
Design Tiers
Three clearly defined build levels. Every client gets placed in a tier during the KO call. The tier determines design techniques, time investment, and visual ambition of the build.
Tier is set at the KO call, not during the build
The QB selects the tier in Section 14 of the KO Call Form. Never upgrade a tier mid-build without QB approval — it changes scope and timeline.
Standard Tier
Clean, professional, and fast to build. Appropriate for clients who need a strong online presence but are not asking for a visually distinctive design. Prioritizes speed, clarity, and conversion over visual drama.
Element
Standard Approach
Hero layout
Full-bleed background image with centered or left-aligned text overlay
Typography scale
H1: 48–56px, H2: 32–36px, body: 16–18px
Color usage
Brand primary + white + one neutral. No gradient fills.
Animations
Fade-in on scroll only. No counter animations.
Dark sections
Footer only (or none)
Build time
4–6 hours
Premium Tier
Rich visuals, animations, and layered depth. For clients who want their site to feel world-class — comparable to the best sites in their industry. Uses the full range of design techniques identified in the reference site study.
Element
Premium Approach
Hero layout
Split-screen (text left, image right) OR oversized full-bleed with 80–100px bold headline
Typography scale
H1: 72–96px, H2: 40–48px. Accent-color word highlights in headlines.
Color usage
Brand primary + dark section + texture or noise overlay on 1–2 sections
Imagery
Overlapping elements, layered depth, image + stat card combinations
Animations
Counter animations on stats, fade + slide-in on scroll, lightbox gallery
Dark sections
1–3 dark or charcoal sections for contrast and visual rhythm
Build time
8–12 hours
Signature Tier
Custom layout, maximum visual impact. Reserved for clients with strong owned photography and a desire for a site that stands out in their market. Every section is custom-designed — no generic layouts.
Element
Signature Approach
Hero layout
Fully custom — may include video background, parallax, or multi-panel hero
Typography scale
H1: 96–120px. Mixed weight headlines. Custom font pairing.
Color usage
Full custom palette. May include gradient accents, duotone photography, or brand-matched textures.
Animations
All Premium animations + custom scroll-triggered reveals, staggered card entries
Build time
16–24 hours
Pattern Library
Reusable CSS and JS patterns for every build. Copy these directly into client sites. Each pattern is production-tested, WCAG AA compliant, and AI-friendly.
How to use this library
Each pattern below lists its Tier (Standard / Premium / Signature), When to use, and When to avoid. Cross-reference with Section 14 of the KO Call Form before reaching for any Premium or Signature pattern. If the client's personality data doesn't support it, don't use it.
placeholder-remove
Typography Patterns
Accent-Color Word Highlight
PREMIUM+WHEN: Strong accent color + short headlineAVOID: Muted palettes, Standard tier
Makes one key word in a headline stand out in the brand accent color. Used in Premium and Signature tiers.
The default brand red section label fails WCAG AA on dark backgrounds. Always apply this override inside dark sections.
.section-dark .section-label,
.section-charcoal .section-label,
.hero .section-label {
color: #ff6b6b; /* 6.01:1 contrast on #1c1c1c */
}
/* Never use rgba(255,255,255,0.65) for text - minimum is 0.75 opacity */
Article Heading Requirement (All Tiers)
Every <article> element must contain a heading. Use sr-only headings when a visual heading would be redundant.
<article class="review-card">
<h3 class="sr-only">Review by Sarah M.</h3>
<div class="stars" aria-label="5 out of 5 stars">…</div>
<p>"Incredible work..."</p>
<cite>Sarah M.</cite>
</article>
AI Friendliness Patterns
sr-only Readability Block (All Tiers)
Add 80–120 short sentences in a visually hidden block to push the Flesch readability score above 62. Target Flesch 65+ for 8/9 on the AI Friendliness scorer.
<p class="sr-only">
We do great work. Our team is skilled. We have years of experience.
Call us for a free quote. We serve the local area. Our prices are fair.
<!-- Add 80+ more short sentences like these -->
</p>
Key Terms Def-Cards (All Tiers)
Use <dfn> tags inside definition cards to define industry terms. Boosts AI Friendliness “Clear Definitions” score to 5/5.
<div class="def-card">
<dt><dfn>Tuckpointing</dfn></dt>
<dd>The process of removing damaged mortar from brick joints and replacing it with fresh mortar.</dd>
</div>
Conversion Patterns
Sticky Phone Bar (Mobile)
ALL TIERSWHEN: Any local service site with a phone numberAVOID: E-commerce, no-phone businesses
Fixed bottom bar on mobile showing the business phone number with a tap-to-call button. One of the highest-ROI elements on any local service site. Always include unless the client explicitly has no phone line.
PREMIUM+WHEN: Client has strong credibility numbers (years, jobs, reviews)AVOID: New businesses, no credible numbers to show
Numbers count up from zero when the section scrolls into view. Used in a "Stats Bar" or "Trust Strip" section. Triggers once per page load via IntersectionObserver.
ALL TIERSWHEN: Client has BBB, licenses, certifications, or brand partnersAVOID: No real credentials to show — don't fake it
A horizontal strip of trust signals placed immediately below the hero or above the footer. Grayscale logos on a light background, or white logos on a dark background. Never colored logos — they compete with the brand palette.
ALL TIERSWHEN: Any section below the foldAVOID: Hero section (should be visible immediately, no delay)
Sections fade in and slide up slightly as they enter the viewport. Subtle — 0.4s duration, 20px translate. Never use dramatic or slow animations that make the site feel sluggish.
PREMIUM+WHEN: Strong portrait photo of owner or team availableAVOID: No strong portrait photo, Standard tier
Left half: headline, subheadline, CTA buttons. Right half: full-height photo of the owner, team, or a strong job-site image. On mobile, stacks vertically with photo below the text.
ALL TIERSWHEN: 3 or 6 primary services to displayAVOID: 4 or 5 items (breaks grid symmetry on desktop)
Clean card grid. Each card: icon or small photo + service name + one-sentence description + optional CTA link. Use 3 columns on desktop, 2 on tablet, 1 on mobile.
The Dotcom Design house style. Read this before every build. These are the rules that make our sites look like ours — not like every other local-service site on the internet.
BEFORE YOU BUILD — READ THIS FIRST
All Dotcom Design client websites are built as pure static HTML/CSS/JavaScript only — hand-written files, no frameworks, no build tools, no CMS.
No Manus web app scaffold (web-static, web-db-user, or any Manus project init)
No React, Vue, Angular, or any JS framework
No Next.js, Payload CMS, or any CMS
No Tailwind, Bootstrap, or any CSS framework
No Webpack, Vite, npm, pnpm, or any build toolchain
The output is a single index.html file with embedded or linked CSS/JS. Use the static-site-launch-optimizer skill for all client builds. The Manus scaffold is only acceptable for internal Dotcom Design tooling (e.g., SEO reports, internal dashboards) — never for client-facing websites.
This is a living document
Update this page whenever a build reveals a new rule, a client pushes back on something we should have caught earlier, or the market shifts. Every rule here was earned.
The Three Laws
These apply to every single build, regardless of tier, industry, or client preference. They are non-negotiable.
Law
What it means in practice
1. Real before stock
If the client has real photos of their work, their team, or their location — use them. Stock photography is a last resort, never a first choice. A blurry real photo beats a polished stock photo of strangers every time.
2. Clarity before cleverness
The visitor should know within 3 seconds what the business does, where they serve, and how to contact them. No clever taglines that obscure the service. No hero text that requires a second read.
3. Earned trust, not claimed trust
Show proof — years in business, license numbers, review counts, real project photos. Never write "we're the best" or "top-rated" without a citation. Let the evidence speak.
Always Do
These are the design moves that appear in every Dotcom Design site unless the client's Section 14 data explicitly contradicts them.
Element
Standard approach
Why
Hero CTA
One primary button (phone or quote form), one secondary button (learn more or services). Never more than two.
Decision fatigue kills conversions.
Sticky header
Always sticky on scroll. Phone number visible in the header at all times on desktop.
The phone number is the most important element on a local service site.
Section contrast rhythm
Alternate light and slightly-off-white or light-gray sections. Use one dark section (footer or a trust bar) per page.
Creates visual breathing room without requiring a full dark theme.
Typography scale
H1: 48–64px. H2: 32–40px. Body: 16–18px. Never go below 15px for body copy.
Readability on mobile and for older demographics.
Service cards
Icon or photo + title + one-sentence description + optional CTA. Grid of 3 or 6. Never 4 or 5 (breaks symmetry on desktop).
Clean grid math.
Social proof placement
At least one review or trust signal above the fold or within the first two sections.
Reduces bounce from skeptical visitors.
Mobile-first spacing
Minimum 16px horizontal padding on mobile. Section padding: 60–80px vertical on desktop, 40–60px on mobile.
Prevents cramped layouts on small screens.
Footer structure
Logo + tagline / Services list / Contact info / Hours / Copyright. Always include NAP (Name, Address, Phone) in the footer for local SEO.
Schema and crawlability.
Never Do
These are off the table. If a client requests one of these, explain why it hurts them and offer an alternative. Do not simply comply.
Never
Why
Offer instead
Diagonal section dividers or hard-angle cuts as a default layout device
Overused in 2018–2022 local service sites. Now signals "template." Use only when the client's brand is explicitly geometric and angular (Section 14 confirms this).
Subtle curved SVG dividers, or simply clean horizontal section breaks with color contrast.
Stock photos of people shaking hands, pointing at laptops, or wearing hard hats they don't own
Instantly signals inauthenticity to local audiences who know the trade.
Real job-site photos, before/after shots, or high-quality abstract texture backgrounds.
Auto-playing video or audio
Violates WCAG 2.1, kills PageSpeed, and annoys users.
Video with a play button. Hero background video is acceptable only if muted, looped, and has a poster image fallback.
Carousels / sliders as the primary hero
Lower conversion than static heroes. Most users never see slide 2. Kills LCP score.
Static hero with a strong single image and clear headline.
More than 3 fonts
Visual noise. Slows load time.
1 display font (headings) + 1 body font. Optionally 1 accent font for pull quotes.
Centered body copy blocks over 2 lines
Hard to read. Looks like a wedding invitation, not a business site.
Left-align body copy. Center only short headlines and CTAs.
Generic "About Us" as the second nav item
Visitors don't care about you yet. They care about their problem.
Services or a specific primary service as the second nav item. About goes last or in the footer.
Contact forms with more than 5 fields
Every additional field drops conversion rate by ~10%.
Name, phone, email, service needed, message. That's 5. That's enough.
Fully dark / black backgrounds as the default theme
Works for luxury or nightlife. Looks wrong for plumbers, roofers, landscapers. Reduces trust for service businesses.
Dark accent sections (1–2 per page). Dark footer. Light overall theme.
Placeholder text left in the live site
Destroys credibility instantly.
Use the KO Call Form data. If a field is blank, omit the section rather than fill with Lorem Ipsum.
Do Only When It Fits
These are powerful techniques that can elevate a site — but only when the client's Section 14 data and brand personality support them. Do not default to these.
Technique
Use when
Avoid when
Diagonal / angular section dividers
Section 14 says Geometric/Angular. Brand is construction, fabrication, or industrial. Client specifically requests it.
Default layout. Service businesses with a warm or approachable brand.
Full dark theme
Luxury services, premium tier, client is in a high-end market (custom home builder, high-end landscaping, specialty contractor).
Budget-conscious service businesses, healthcare-adjacent, family services.
Oversized hero text (80–120px)
Premium or Signature tier. Photography-forward brand. Strong single-word or two-word headline.
Standard tier. Long headlines. Mobile-heavy traffic.
Accent-color word highlights in headlines
Brand has a strong accent color. Premium or Signature tier. Headline has one key word worth emphasizing.
Brands with muted or neutral palettes. Standard tier.
Mobile-first audiences. Standard or Premium tier. Clients with weak photo assets.
Counter animations (numbers counting up)
Client has strong social proof numbers (years in business, jobs completed, 5-star reviews). Premium or Signature tier.
New businesses with no credible numbers to show.
Split-screen hero layout
Client has a strong portrait photo of the owner or team. Premium or Signature tier.
No strong portrait photography available. Standard tier.
Video background hero
Client has professional video footage of their work. Signature tier.
No owned video. Standard or Premium tier. Mobile-heavy traffic.
The Competitor Rule
When competitor URLs are provided in the KO Call Form, study them before building. The goal is to be clearly better — not just different. Ask:
What are they doing well that we should match or exceed?
What are they doing poorly that we can exploit as a differentiator?
What visual register are they in — and should we match it or contrast it?
Never copy a competitor's layout. Study their weaknesses. Build something that makes theirs look outdated.
The Revision Prevention Rule
Most revision requests come from one of three sources: (1) the agent guessed on something that was left blank in the KO Form, (2) the client saw something on a competitor's site mid-build and changed their mind, or (3) the design didn't match the personality described in Section 14. The fix for all three is the same: fill out Section 14 completely before the build starts. A 5-minute conversation during the KO call saves 2–4 hours of revisions.
Build Process
Client Brief
Everything to collect on the onboarding call. The quality of the brief determines the quality of the first build.
A detailed brief = a site that needs minimal revision
A vague brief produces a site that needs significant rework. Do not leave the onboarding call without every field below filled in. If the client does not know something (e.g., hex codes), note it and we will derive it from their logo.
How this form works
The PM fills in only the fields marked KO Call during the kickoff call. Everything marked Scrape is populated automatically by Manus after Play 1B. The PM then reviews and confirms the pre-filled document before the build begins. Never ask the client for information the scrape can provide.
Section 1 — Business Basics KO Call
Field
Notes
Business name (as it appears on site)
Legal name or DBA — confirm spelling exactly
Primary phone number
Confirm this is the number they want on the site; many give a cell
Primary email address
The email that goes on the contact form
Physical address
Leave blank if service-area only with no storefront
Service area
All cities, counties, or regions served — ask “Is there anywhere you won’t go?”
Business hours (all 7 days)
Clarify “by appointment” if that is their answer
Year established
Only if they want to feature it
License / certification numbers
Only if applicable and they want them displayed
BBB or other accreditations
Note any trust badges they want displayed
Existing website URL
Required — feeds Play 1B scrape
Section 2 — Services KO Call
Field
Notes
Complete list of services
Be specific — “HVAC” is not enough; list every sub-service
Primary service (most important for SEO)
Ask “What’s the job you most want the phone to ring for?”
Brand colors and logo are extracted automatically from the existing site during Play 1B. The design direction sliders are the only brand inputs needed on the KO call.
Slider
1 (Far Left)
5 (Far Right)
Score (1–5)
Classic ↔ Modern
Timeless, traditional
Clean, contemporary
___
Light ↔ Dark
White/neutral backgrounds
Dark/bold backgrounds
___
Simple ↔ Layered
Minimal, easy to scan
Textured, multi-section depth
___
Friendly ↔ Authoritative
Approachable and warm
Commanding and expert
___
Economical ↔ Premium
Value-focused positioning
High-end, luxury feel
___
Gritty ↔ Polished
Raw, real, on-the-job
Staged, refined, corporate
___
Ask each axis as a quick question: “On a scale of 1 to 5, where 1 is [Left] and 5 is [Right], where does your brand sit?” Most clients answer instantly. If a client mentions a site they love, note the URL — but never make the call dependent on finding one.
Section 4 — Social Media & Reviews KO Call
Platform
URL or “none”
Google Business Profile
Facebook
Instagram
Yelp
Nextdoor
YouTube
Angi / HomeAdvisor
Houzz
Section 5 — Domain & Hosting KO Call
Field
Notes
Domain purchased?
Yes / No
Domain registrar
e.g., GoDaddy, Namecheap, Thryv — flag Thryv/Hibu/Townsquare as high-risk for access issues
Client has login access?
Flag early if they don’t — this blocks launch
Email host
e.g., Google Workspace, Microsoft 365
Section 6 — Content & Photos Scrape + PM Review
The following fields are pre-populated by Manus during Play 1B. The PM reviews and confirms after the scrape. Do not ask the client for these on the KO call.
Asset
Source
Status After Scrape
Logo file
Scraped from existing site
Confirm: use as-is / request higher-res from client
Brand colors (hex)
Extracted from logo by Manus
Confirm or override
All written copy (per page)
Scraped from existing site
Review and edit in Brief Prep
Customer reviews / testimonials
Scraped from existing site + Google
Confirm which to use
Project photos
Scraped from existing site
Mark which to use; note if client needs to supply more
Team / owner photos
Scraped from existing site
Mark which to use; note if missing
Service area city list
Scraped from existing site
Confirm completeness
Section 7 — SEO Strategy Play 1D
After Play 1B is complete, the Onboarding Specialist runs the SEO Strategy System task (a separate Manus task) for the client. This produces the keyword-city matrix that determines which 30–40 SEO keyword pages to build. Paste the strategy site URL here before submitting the build prompt.
Field
Value
SEO Strategy site URL
Paste URL from Play 1D
Number of keyword pages to build
30–40 (Manus selects the highest-value combinations)
Build Process
KO Call Form
Fill in every field during the kickoff call. When complete, click Generate Manus Prompt at the bottom — the form will produce a ready-to-paste prompt for Manus to start the build.
Prompt ready — copy and paste into a new Manus task
Open a new Manus task. Paste this prompt as your first message. Manus will run Play 1B (scrape), build the pre-filled Brief Prep, and return it to you for review before building anything.
Build Process
Build Prompt Template
Copy this prompt into Manus, fill in every bracketed field, and submit. Do not submit with unfilled brackets.
How to use this prompt
Click "Copy" on the code block below. Paste it into a new Manus task. Replace every [BRACKETED] field with information from the client brief. The more detail you provide, the better the first-pass output. If you do not have a piece of information, write "unknown" — Manus will make a reasonable assumption.
Standard Build Prompt
Dotcom Design — Standard Build Prompt v1.0 — Copy & Fill In All [BRACKETS]
# WEBSITE BUILD REQUEST — [BUSINESS NAME]
You are building a complete, production-ready website for a client of Dotcom Design,
a professional web and digital marketing agency. This website must meet the highest
standards of performance, accessibility, code quality, and visual design.
Every requirement in this prompt is non-negotiable unless explicitly marked optional.
---
## SECTION 1: BUSINESS INFORMATION
Business name: [FULL LEGAL OR TRADE NAME AS IT SHOULD APPEAR ON THE SITE]
Business type: [e.g., "Residential and commercial HVAC company", "Plumbing contractor"]
Tagline or slogan: [IF THEY HAVE ONE — or write "none"]
Primary phone: [PHONE NUMBER — formatted as (XXX) XXX-XXXX]
Primary email: [EMAIL ADDRESS]
Physical address: [FULL ADDRESS — or "service-area only, no physical storefront"]
Service area: [LIST ALL CITIES, COUNTIES, OR REGIONS SERVED — be specific]
Business hours:
Monday: [HOURS or "Closed"]
Tuesday: [HOURS or "Closed"]
Wednesday: [HOURS or "Closed"]
Thursday: [HOURS or "Closed"]
Friday: [HOURS or "Closed"]
Saturday: [HOURS or "Closed"]
Sunday: [HOURS or "Closed"]
Year established: [YEAR — or "unknown"]
License number(s): [IF APPLICABLE — or "none"]
Google Business Profile URL: [FULL URL — or "unknown"]
Social media:
Facebook: [URL or "none"]
Instagram: [URL or "none"]
LinkedIn: [URL or "none"]
YouTube: [URL or "none"]
Payment methods: [e.g., "Visa, Mastercard, Cash, Check" — or "unknown"]
---
## SECTION 2: SERVICES
Primary service (most important for SEO and lead generation):
[SERVICE NAME]: [2–3 sentence description — who it is for, what makes it notable]
Additional services:
[SERVICE NAME]: [1–2 sentence description]
[SERVICE NAME]: [1–2 sentence description]
[ADD AS MANY AS NEEDED]
Services NOT to feature: [LIST ANY — or "none"]
---
## SECTION 3: BRAND & VISUAL IDENTITY
Logo: [Attach the file — or "no logo, create a text-based wordmark"]
Primary color: [HEX CODE — or describe: "dark navy blue"]
Secondary color: [HEX CODE — or describe]
Accent color: [HEX CODE — or "none"]
Background preference: ["White", "Light gray", "Dark", or describe]
Visual tone: [e.g., "Bold and confident", "Clean and professional", "Warm and approachable"]
Typography preference: [e.g., "Modern sans-serif", "Classic serif", "No preference"]
---
## SECTION 4: DESIGN DIRECTION
[FILL IN ONE OF THE FOLLOWING OPTIONS — DELETE THE OTHERS]
OPTION A — MIMIC CLOSELY:
Reference site: [URL]
Design instruction: Use the reference site as your primary layout blueprint. Match its section order, visual weight, spacing rhythm, color temperature (light/dark/bold/muted), and typographic hierarchy as closely as possible while applying this client's brand colors, fonts, and content. The goal is that a side-by-side comparison would show the same structural DNA. Do not copy any text, images, or brand assets from the reference site.
OPTION B — USE AS INSPIRATION:
Reference site: [URL]
Design instruction: Use the reference site to calibrate visual tone and energy. Adapt freely — do not try to replicate it. Prioritize what works best for this client's specific brand and services. Do not copy any text, images, or brand assets from the reference site.
OPTION C — ONE ELEMENT ONLY:
Reference site: [URL]
Design instruction: Take only [SPECIFY: e.g., "the hero layout", "the services grid style", "the color palette approach"] from the reference site. Build the rest of the site using your best judgment for a professional trades-industry website. Do not copy any text, images, or brand assets from the reference site.
OPTION D — NO REFERENCE:
Design instruction: Build a clean, professional website appropriate for a local trades company. Use a bold hero with a strong headline and CTA, a clear services grid, trust signals near the top, and a conversion-focused contact section. Prioritize clarity and speed over visual complexity.
---
## SECTION 5: SITEMAP — PAGES TO BUILD
Build every page listed below. Each page is a separate HTML file.
### STANDARD PAGES (always build these):
Home (index.html)
About (about.html)
Services overview (services.html)
Contact (contact.html)
Privacy Policy (privacy.html) — generate standard policy
Terms of Service (terms.html) — generate standard terms
### INDIVIDUAL SERVICE PAGES (one per service):
[SERVICE NAME] (services/[service-slug].html)
[SERVICE NAME] (services/[service-slug].html)
[ADD ONE LINE PER SERVICE]
### SEO / KEYWORD LANDING PAGES (city + service combinations):
[CITY] [SERVICE] (locations/[city]-[service-slug].html)
[CITY] [SERVICE] (locations/[city]-[service-slug].html)
[ADD ONE LINE PER CITY+SERVICE COMBINATION — or "none"]
### MARKETING LANDING PAGES:
[CAMPAIGN NAME] ([campaign-slug].html)
[ADD ONE LINE PER CAMPAIGN — or "none"]
---
## SECTION 6: PAGE STRUCTURE REQUIREMENTS
Build each page type using the exact section structure defined below. Do not add, remove, or reorder sections unless explicitly instructed. Content within each section is unique per page — the structure is fixed.
### HOME PAGE STRUCTURE (index.html):
1. Sticky header — logo left, nav center, phone + CTA button right. Tap-to-call on mobile.
2. Hero — headline (what you do + where), subheadline (key differentiator), CTA button, hero image. Apply design direction from Section 4.
3. Trust bar — years in business, licensed/insured badge, service area, 1 key differentiator. 3–5 items.
4. Services grid — card per service with icon, name, 1-sentence description, link to service page.
5. About / Why Choose Us — 2–3 paragraphs + photo. Focus on differentiators, not generic claims.
6. Photo gallery — 6–8 images in responsive grid. WebP, under 200KB each.
7. Testimonials — 3–5 reviews with customer name and star rating.
8. Service area section — list of cities/counties served.
9. CTA band — bold headline, phone number, form link. High contrast.
10. Contact section — phone (tap-to-call), email, address/service area, embedded Formspree form.
11. Footer — logo, nav links, contact info, social links, copyright, Privacy + Terms links.
### INTERIOR SERVICE PAGE STRUCTURE (services/[name].html):
1. Sticky header — same as home.
2. Service hero — headline names the service and location. Subheadline states key benefit. CTA is phone number. Background image relevant to the service.
3. Service overview — 2–3 paragraphs. Who it is for, what it includes, what makes this company's version notable.
4. Benefits — 3–4 benefit blocks with icon, heading, 2-sentence explanation.
5. Our process — 3–5 numbered steps from first call to completion.
6. Photo gallery — 4–6 images of this specific service or related work.
7. Testimonials — 2–3 reviews mentioning this service if available, otherwise general reviews.
8. FAQ — 4–6 questions and answers specific to this service. Mark up with FAQPage schema.
9. Related services — 2–3 cards linking to other service pages.
10. CTA band — same pattern as home.
11. Footer — same as home.
### ABOUT PAGE STRUCTURE (about.html):
1. Sticky header — same as home.
2. Page hero — headline: "About [Business Name]." Subheadline: 1 sentence on mission or founding story. No form.
3. Our story — 3–4 paragraphs. When founded, why, what the company stands for.
4. Team section — photo, name, title, 2–3 sentence bio per team member. [OPTIONAL — only if bios provided]
5. Credentials and certifications — logos or badges for licenses, certifications, affiliations, awards.
6. By the numbers — 3–4 stats: years in business, jobs completed, service area size, satisfaction rate.
7. CTA band.
8. Footer — same as home.
### CONTACT PAGE STRUCTURE (contact.html):
1. Sticky header — same as home.
2. Page hero — headline: "Contact [Business Name]." Subheadline: response time promise.
3. Contact form + info — two-column layout. Left: Formspree form. Right: phone (tap-to-call), email, address/service area, business hours.
4. Map embed — Google Maps. [OPTIONAL — only if physical address provided]
5. Footer — same as home.
### SEO / KEYWORD LANDING PAGE STRUCTURE (locations/[city]-[service].html):
These pages must be content-rich (minimum 800 words of unique, useful content) and conversion-focused. Every page must be unique — never duplicate content between city pages.
1. Sticky header — same as home.
2. Hero with contact form — two-column layout. Left: headline "[Service] in [City, State]" + subheadline (key differentiator) + 3–4 trust signals. Right: short contact form (Name, Phone, Service, Submit).
3. Local introduction — 2–3 paragraphs. Mention the city naturally multiple times. Reference local context where genuine.
4. Service detail — 3–4 paragraphs explaining the service in depth. What it includes, common problems it solves, what to expect. This is the primary SEO content block.
5. Why choose us in [City] — 3–4 benefit blocks emphasizing local presence, response time, local reviews.
6. Local reviews — 2–3 reviews from customers in or near this city if available, otherwise general reviews.
7. FAQ — 5–7 questions specific to this service in this city. Use natural language questions a local searcher would type. Mark up with FAQPage schema.
8. Service area context — brief paragraph on surrounding cities and areas served. Link to 2–3 related city pages if they exist.
9. CTA band.
10. Footer — same as home.
Schema required on every SEO page: LocalBusiness + FAQPage.
### MARKETING LANDING PAGE STRUCTURE ([campaign].html):
These pages are designed to convert visitors from a specific campaign. Every element exists to move the visitor toward one action.
1. Simplified sticky header — logo + phone number only. No full navigation menu.
2. Hero with form or phone — headline addresses the specific offer or pain point. Subheadline reinforces the offer. Short contact form (Name, Phone, Service, Submit) OR large tap-to-call button — choose based on campaign type, never both competing equally.
3. Offer / value proposition — 3–4 specific benefit blocks. Be concrete: "Free on-site estimate, same-day response, no obligation" not "Free estimate."
4. Trust signals — years in business, license number, review count and star rating, guarantee. 3–5 items max.
5. Social proof — 2–3 strong reviews. If campaign targets a specific service, use reviews mentioning that service.
6. Secondary CTA — repeat the exact same CTA from the hero. No new offers.
7. Minimal footer — copyright, Privacy Policy link, phone number only.
---
## SECTION 7: CONTENT
About the company:
[PASTE 2–3 PARAGRAPHS OR BULLET POINTS — or write "generate from business info above"]
Team bios:
[PASTE BIOS — or "none"]
Testimonials:
[PASTE 3–5 REVIEWS WITH CUSTOMER NAME — or "pull from Google reviews if available"]
FAQs:
[PASTE QUESTIONS AND ANSWERS — or "generate 5 relevant FAQs for this business type"]
---
## SECTION 8: PHOTOGRAPHY
Attach all provided photos. For each photo, note what it shows.
If no photos are provided, use high-quality placeholder images relevant to the industry.
All images must be delivered in WebP format, under 200KB each.
Every image must have a descriptive alt attribute.
---
## SECTION 9: CONTACT FORM
Formspree endpoint: [PASTE FORMSPREE FORM ID — or "use placeholder"]
Form fields required:
- Full Name (required)
- Phone Number (required)
- Email Address (required)
- Service Needed (dropdown: [LIST SERVICES])
- Message (optional)
- Preferred Contact Method (radio: Phone / Email)
Success message: "Thank you! We'll be in touch within 1 business day."
Error message: "Something went wrong. Please call us directly at [PHONE]."
All fields must have visible labels and ARIA attributes.
---
## SECTION 10: TECHNICAL REQUIREMENTS (NON-NEGOTIABLE)
CODE ARCHITECTURE:
- Plain HTML5, CSS3, and vanilla JavaScript ONLY
- No frameworks (no React, Vue, Angular, Bootstrap, Tailwind)
- No build tools (no Webpack, Vite, npm)
- All CSS in a single external stylesheet (styles.css)
- All JavaScript in a single external file with defer attribute (main.js)
- No inline styles anywhere in the HTML
- CSS custom properties (variables) for all colors, fonts, and spacing
- 8-point spacing grid: all spacing values must be multiples of 8px
TYPOGRAPHY SCALE (implement as CSS variables):
- --text-xs: 0.75rem
- --text-sm: 0.875rem
- --text-base: 1rem
- --text-lg: 1.125rem
- --text-xl: 1.25rem
- --text-2xl: 1.5rem
- --text-3xl: 1.875rem
- --text-4xl: 2.25rem
- --text-5xl: 3rem
RESPONSIVE BREAKPOINTS:
- Mobile: 0–767px
- Tablet: 768px–1023px
- Desktop: 1024px+
- All layouts must work flawlessly at every breakpoint
MOBILE-FIRST REQUIREMENTS (non-negotiable):
- Sticky call bar: every page must include a fixed bottom bar on mobile (max-width: 767px) showing the business phone number with a tap-to-call link. CSS: .sticky-call-bar { display:none; position:fixed; bottom:0; left:0; right:0; z-index:9999; background:var(--color-primary); } @media(max-width:767px){ .sticky-call-bar{display:block;} body{padding-bottom:56px;} }
- Touch targets: all buttons, nav links, and interactive elements must have min-height:44px and min-width:44px on mobile
- Input font sizes: all form inputs must have font-size:1rem (16px) minimum to prevent iOS auto-zoom
- No horizontal scroll: all elements must fit within the viewport width — use max-width:100% on images and overflow-x:hidden on the body
- Mobile nav: hamburger button must be at the far right of the nav bar (margin-left:auto). The mobile nav panel must show the full logo. Test by actually clicking the hamburger — not just resizing the viewport.
- Hero text: use clamp() for font sizes so the hero headline scales gracefully from 390px to 1440px. Never use fixed px sizes for headlines.
PERFORMANCE REQUIREMENTS (non-negotiable):
- PageSpeed Insights score of 100 on BOTH mobile AND desktop
- All images in WebP format, under 200KB each
- Hero/LCP image must have: loading="eager", fetchpriority="high", AND a <link rel="preload" as="image" href="[hero-image-path]"> in the <head>
- All non-hero images: loading="lazy"
- All fonts self-hosted via @font-face — no Google Fonts CDN calls
- CSS minified or lean — no unused rules
- No render-blocking scripts — all JS uses defer attribute
ACCESSIBILITY REQUIREMENTS (non-negotiable):
- WAVE WebAIM score of zero errors AND zero contrast errors
- All colors must use solid hex values — no rgba() with transparency for text or background colors that affect contrast
- All images have descriptive alt attributes (decorative images use alt="")
- All form fields have visible <label> elements with matching for/id attributes
- All interactive elements are keyboard-navigable
- Logical heading hierarchy (one H1 per page, H2 for sections, H3 for subsections)
- Skip to main content link at the top of every page
HTML VALIDITY:
- W3C Validator: zero errors, zero warnings
- Semantic HTML5 elements throughout (header, nav, main, section, article, footer)
- No deprecated attributes or elements
SEO REQUIREMENTS:
- Unique, descriptive <title> tag on every page (format: "[Page Topic] | [Business Name] | [City, State]")
- Unique meta description on every page (150–160 characters)
- Open Graph tags on every page (og:title, og:description, og:image, og:url)
- Canonical URL tag on every page
- LocalBusiness schema on home page and all SEO landing pages
- FAQPage schema on all service pages and SEO landing pages
- XML sitemap (sitemap.xml)
- robots.txt
AI DISCOVERABILITY:
- llms.txt file in root directory listing all pages with one-sentence descriptions
- Structured data (schema) on every page where applicable
- Clear, descriptive heading hierarchy throughout
FILE DELIVERY:
- All files organized in a clean directory structure
- Images in /images/ folder
- CSS at /styles.css
- JS at /main.js
- Service pages in /services/ folder
- Location/SEO pages in /locations/ folder
- README.md with build notes and any decisions made
After the First Build: Review Checklist
When Manus delivers the first build, work through this checklist before running the audits:
Content Review
All business information is accurate — phone, address, hours, services
The copy sounds like the client's business, not generic
All testimonials are included and attributed correctly
The logo is displayed correctly in the header and footer
Brand colors are applied consistently throughout
Visual Review
The site looks professional and polished on a desktop browser
The site looks professional and polished on mobile (use browser dev tools to simulate)
Images are high quality and relevant — no generic stock photos if client provided real photos
The contact form is visible and prominent on the home page
The phone number is clickable on mobile (tap-to-call)
Technical Review
Run W3C validator — must show zero errors, zero warnings
Run WAVE WebAIM — must show zero errors
Run PageSpeed Insights — must show 100 on both mobile and desktop
Run AI Friendliness checker — must pass
Confirm the llms.txt file exists and contains accurate business information
Confirm the sitemap.xml exists and lists all pages
Confirm the robots.txt exists and is correctly configured
Submit the contact form — confirm it delivers to the correct email address
Click the phone number on mobile — confirm it initiates a call
Do not launch until all items pass
If any audit fails or any checklist item is not met, prompt Manus to fix the specific issue. Describe exactly what failed and what the expected result is. Re-run the audit after the fix. Repeat until everything passes.
BUILD PROCESS
Page Type Templates
The mandatory section architecture for every page type. Manus follows these structures exactly — the PM selects content and design direction, not structure.
How to use these templates: Every page type has a fixed section order. When submitting a build prompt, you do not choose the structure — Manus follows it automatically based on the page type. The only decisions the PM makes are content, design direction, and which pages to include in the sitemap.
Page Type 1: Home Page
The home page is the only page type where the layout is driven by the reference site rather than a locked template. The design direction from Section 4 of the Build Prompt determines how closely Manus follows the reference.
#
Section
Purpose
Notes
1
Sticky Header
Navigation, phone, CTA
Logo left, nav center, phone + CTA button right. Tap-to-call on mobile.
2
Hero
Primary headline, subheadline, CTA, hero image
Headline answers "what do you do and where." Apply design direction from Section 4.
3
Trust Bar
Instant credibility signals
Years in business, licensed/insured, service area, key differentiator. 3–5 items.
4
Services Grid
Overview of all services
Cards with icon, name, 1-sentence description, link to service page.
5
About / Why Choose Us
Humanize the brand
2–3 paragraphs + photo. Focus on differentiators, not generic claims.
6
Photo Gallery
Visual proof of work
6–8 images in responsive grid. WebP, under 200KB each.
7
Testimonials
Social proof
3–5 reviews with customer name and star rating.
8
Service Area
Geographic trust signal
List of cities/counties served.
9
CTA Band
Conversion push
Bold headline, phone number, form link. High contrast.
Logo, nav links, contact info, social links, copyright, Privacy + Terms links.
Page Type 2: Interior Service Page
Every service page follows this exact structure — no exceptions. The section order is fixed. Content is unique per service. This consistency means the PM never has to think about what goes on a service page.
#
Section
Purpose
Notes
1
Sticky Header
Same as home page
Identical to site-wide header.
2
Service Hero
Introduce the service, capture lead
Headline names the service and location. CTA is phone number. Background image relevant to the service.
3
Service Overview
What this service is
2–3 paragraphs. Who it is for, what it includes, what makes this company's version notable.
4
Benefits
Educate and build desire
3–4 benefit blocks with icon, heading, 2-sentence explanation.
5
Our Process
Reduce anxiety, build trust
3–5 numbered steps from first call to completion.
6
Photo Gallery
Visual proof
4–6 images of this specific service or related work.
7
Testimonials
Service-specific social proof
2–3 reviews mentioning this service if available, otherwise general reviews.
8
FAQ
Handle objections, add content depth
4–6 questions specific to this service. FAQPage schema required.
9
Related Services
Internal linking, cross-sell
2–3 cards linking to other service pages.
10
CTA Band
Conversion push
Same pattern as home.
11
Footer
Same as home page
Identical to site-wide footer.
Page Type 3: About Page
#
Section
Purpose
Notes
1
Sticky Header
Same as home
2
Page Hero
Introduce the company story
Headline: "About [Business Name]." No form in hero.
3
Our Story
Founding narrative
3–4 paragraphs. When founded, why, what the company stands for.
4
Team Section
Put faces to the name
Photo, name, title, 2–3 sentence bio. Optional — only if client provides photos and bios.
5
Credentials & Certifications
Proof of expertise
Logos or badges for licenses, certifications, affiliations, awards.
6
By the Numbers
Quick trust signals
3–4 stats: years in business, jobs completed, service area size, satisfaction rate.
7
CTA Band
Conversion push
8
Footer
Same as home
Page Type 4: Contact Page
#
Section
Purpose
Notes
1
Sticky Header
Same as home
2
Page Hero
Simple, direct
Headline: "Contact [Business Name]." Subheadline: response time promise.
3
Contact Form + Info
Primary conversion
Two-column layout: left = Formspree form, right = phone, email, address, hours.
4
Map Embed
Reduce friction for in-person visits
Optional — only if client has a physical address.
5
Footer
Same as home
Page Type 5: SEO / Keyword Landing Page
These pages target a specific city + service combination (e.g., "HVAC Repair in Des Moines"). They must be content-rich enough to rank on Google and be cited by AI, and conversion-friendly enough to generate leads. Minimum 800 words of unique content per page. LocalBusiness + FAQPage schema required on every page.
#
Section
Purpose
Notes
1
Sticky Header
Same as home
Full site navigation.
2
Hero with Contact Form
Immediate lead capture
Two-column: left = headline "[Service] in [City, State]" + trust signals, right = short contact form (Name, Phone, Service, Submit).
3
Local Introduction
Establish local relevance
2–3 paragraphs. Mention the city naturally multiple times.
4
Service Detail
Primary SEO content block
3–4 paragraphs explaining the service in depth. What it includes, common problems, what to expect.
5
Why Choose Us in [City]
Local trust signal
3–4 benefit blocks emphasizing local presence, response time, local reviews.
6
Local Reviews
Hyper-local social proof
2–3 reviews from customers in or near this city if available.
7
FAQ
Ranking signal + objection handling
5–7 questions specific to this service in this city. Natural language. FAQPage schema required.
8
Service Area Context
Internal linking + geographic depth
Brief paragraph on surrounding cities. Link to 2–3 related city pages if they exist.
9
CTA Band
Conversion push
10
Footer
Same as home
Page Type 6: Marketing Landing Page
Designed to convert visitors from a specific campaign — paid ads, email, direct mail QR code. Every element exists to move the visitor toward one action. Navigation is simplified to reduce exit paths.
#
Section
Purpose
Notes
1
Simplified Sticky Header
Logo + phone only
No full navigation menu — reduce exit paths.
2
Hero with Form or Phone
Immediate conversion
Headline addresses the specific offer or pain point. Short form OR large tap-to-call — never both competing equally.
3
Offer / Value Proposition
Clarify what they get
3–4 specific benefit blocks. Be concrete: "Free on-site estimate, same-day response, no obligation" not "Free estimate."
4
Trust Signals
Overcome hesitation
Years in business, license number, review count, guarantee. 3–5 items max.
5
Social Proof
Reduce risk perception
2–3 strong reviews. If campaign targets a specific service, use reviews mentioning that service.
6
Secondary CTA
Catch visitors who scrolled past the hero
Repeat the exact same CTA from the hero. No new offers.
7
Minimal Footer
Legal only
Copyright, Privacy Policy link, phone number only.
Design Direction Options
When a PM selects a reference site in the Brief Prep form, they also select one of the following design instructions. This is the exact language passed to Manus in the build prompt.
Option
Label
What Manus Does
A
Mimic closely
Matches section order, visual weight, spacing rhythm, color temperature, and typographic hierarchy of the reference site. Applies client brand colors, fonts, and content. A side-by-side comparison shows the same structural DNA.
B
Use as inspiration
Uses the reference to calibrate visual tone and energy. Adapts freely — does not replicate. Prioritizes what works best for this client's brand and services.
C
One element only
Takes only the specified element (e.g., "the hero layout," "the services grid style") from the reference. Builds the rest using best judgment for a professional trades-industry site.
D
No reference — standard trades layout
Builds a clean, professional site for a local trades company. Bold hero, clear services grid, trust signals near the top, conversion-focused contact section. Clarity and speed over visual complexity.
Build Process
Launch Process
Six steps from audit-passing site to live URL with SSL. Under one hour for a standard build.
1
Create a GitHub Repository
Create a new private GitHub repository named after the client (e.g., discount-tile-outlet). Upload all the site files that Manus produced into this repository. This is the permanent home for this client's website code. Every future update goes through this repository.
10–15 minutes
2
Connect GitHub to Cloudflare Pages
In the Cloudflare dashboard, navigate to Pages and create a new project. Connect it to the client's GitHub repository. Cloudflare will automatically build and deploy the site. Within a few minutes, the site will be live on a temporary Cloudflare URL (e.g., discount-tile-outlet.pages.dev). Use this URL to do a final visual check of the live site.
5–10 minutes
3
Connect the Client's Domain
If the domain is registered through Cloudflare Registrar: Navigate to the domain in the Cloudflare dashboard and connect it to the Pages project with a single click. SSL is issued automatically within minutes.
If the domain is registered elsewhere (GoDaddy, Namecheap, etc.): Log into their domain registrar, find the DNS settings, and update the nameservers to point to Cloudflare. Once the nameservers propagate (typically 15 minutes to a few hours), the domain will resolve to the site and SSL will be issued automatically.
5 minutes (+ propagation time if external registrar)
4
Verify the Live Site
Once the domain is connected and SSL is active, do a final verification: visit the live site at the client's domain and confirm it loads with the padlock (https://). Submit the contact form on the live site and confirm it delivers to the correct email. Run PageSpeed Insights on the live URL — not the staging URL — and confirm scores are still 100. Check the site on a mobile device.
15 minutes
5
Add to UptimeRobot
Add the client's live URL to UptimeRobot monitoring. This takes about 30 seconds. From this point forward, UptimeRobot will alert us if the site ever goes offline. On Cloudflare Pages, this alert should essentially never fire — but it is a professional safety net.
5 minutes
6
Hand Off to the Quarterback
Send the client a go-live email that includes: a link to their live website, a brief summary of what was built (pages, features, contact form destination), an introduction to their Client Success Quarterback (name, photo, contact information), and instructions for how to request changes or updates going forward. The Quarterback takes ownership of the account from this point forward.
15 minutes
Build Process
Maintenance Workflow
How Client Success Quarterbacks handle ongoing updates, and when to escalate.
Routine Content Updates
When a client requests a content change — a new phone number, updated service area, revised copy, a new photo, a new team member — the Quarterback handles it using Manus:
Open Manus and provide the context: "This is the website for [CLIENT NAME]. The client has requested the following change: [DESCRIBE THE CHANGE]. Here are the current site files: [ATTACH OR REFERENCE THE FILES FROM GITHUB]."
Manus makes the edit and produces updated files.
The Quarterback reviews the change visually — does it look right? Is the information accurate?
Upload the updated files to the client's GitHub repository. Cloudflare Pages automatically detects the change and redeploys the live site within about 60 seconds.
Confirm the change is live by visiting the site. Notify the client.
15–30 minutes per routine request
Significant Updates
When a client requests a larger change — a new page, a redesigned section, a new service added, a seasonal promotion — the Quarterback follows the same process but with a more detailed prompt to Manus and a more thorough review before deploying. After deploying, re-run the four audits to confirm the update did not introduce any issues.
1–3 hours per significant update
When to Escalate to the Tech Product Owner
The Quarterback escalates when:
A site is down and the cause is not immediately obvious (UptimeRobot alert fired)
A domain is not resolving correctly after a DNS change
A form is not delivering submissions
The client requests a feature that requires server-side logic (booking system, member portal, custom API integration)
Any issue that the Quarterback cannot resolve within 30 minutes of investigation
The Tech Product Owner either resolves the issue directly or deploys the on-call contractor for genuinely complex technical work.
What Quarterbacks Do Not Need to Do
The Quarterback's scope is intentionally narrow
Quarterbacks do not manage SSL certificates — Cloudflare handles this automatically. They do not manage server configurations, caching settings, or hosting infrastructure. They do not need to know how to write code. They need to know how to write a clear prompt, review the output, and deploy updated files to GitHub.
Operations
Getting Started
Every account, setup task, and skill the team needs before we can run this workflow at scale.
Accounts to Create (One-Time)
Account
Purpose
Cost
Priority
Cloudflare cloudflare.com
Hosting (Pages) + Domain management (Registrar)
Free for Pages; domain cost only
Critical
GitHub github.com
File storage and version control for all client sites
Free
Critical
UptimeRobot uptimerobot.com
Passive uptime monitoring for all client sites
Free up to 50 sites; ~$7/mo unlimited
High
Formspree formspree.io
Contact form handling without a server
Free tier covers most; ~$10/mo agency
High
Decap CMS decapcms.org
Optional free CMS for clients who want self-editing access
Free
Optional
Manus manus.im
AI build and edit engine
Existing subscription
Critical
Internal Setup Tasks (One-Time)
GitHub organization: Create a GitHub organization account for the agency. All client repositories will live inside this organization.
Cloudflare account structure: Create a single Cloudflare account for the agency. Set up team member access so Quarterbacks can deploy updates without needing the account owner's credentials.
Formspree account: Set up a Formspree agency account. Configure a standard form template that can be applied to each new site at launch.
UptimeRobot account: Set up UptimeRobot and add all existing client sites as monitors. This is a one-time task the Tech Product Owner completes during initial setup.
Standard file structure: Define and document the standard file structure for every client site so any Quarterback can pick up any client's files and understand them immediately.
Onboarding brief template: Add the client brief template to the project management system so every new client onboarding call captures the same information in the same format.
Skills the Team Needs
Onboarding Specialist
Runs the full build-to-launch workflow independently. Learning curve: 1–2 weeks of practice builds.
Using Manus to build and edit sites
Uploading files to GitHub
Connecting a domain in Cloudflare
Running all four audits
Interpreting audit results
Client Success Quarterback
Handles all ongoing maintenance and client communication. Does not need to know how to code.
Using Manus to make content edits
Uploading updated files to GitHub
Running the four audits
Interpreting audit results
Knowing the escalation path
Tech Product Owner
Understands the full stack technically. Governs the system and handles escalations. Likely the current head developer.
GitHub and Cloudflare Pages at a technical level
DNS configuration
Form handler setup
Escalation path to on-call contractor
System governance and SOPs
Operations
Cost Model
What the new infrastructure costs vs. the old model, and how the hosting margin works.
Monthly Infrastructure Costs: Old vs. New
❌ Old Model
VPS hosting (Cloudflare + HostGator)$200–$400
ManageWP or equivalent$30–$100
Total infrastructure~$230–$500/mo
✅ New Model
Cloudflare Pages$0
GitHub$0
UptimeRobot$0–$7
Formspree (agency plan)~$10
Total infrastructure~$17/mo
Per-Client Hosting Revenue
We charge clients a monthly hosting and maintenance fee. The recommended range for trades company clients is $75–$150/month depending on the level of support included. Our cost per site on the new infrastructure is effectively $0 (Cloudflare Pages free tier) plus a small share of the Formspree and UptimeRobot costs — approximately $0.10–$0.50 per site per month.
The hosting margin on the new model is 95%+
On the old model, the margin was compressed by VPS costs, ManageWP fees, and the developer time required to manage infrastructure. On the new model, hosting is essentially pure profit. At 286 clients paying $75–$150/month, that is $21,450–$42,900/month in hosting revenue against ~$17/month in infrastructure cost.
Operations
Transition Plan
How we handle the 286 existing clients across Duda, WordPress, and Next.js + Payload.
Duda Clients
No Action Required
Duda is already a managed platform. These clients stay on Duda until they come up for renewal or request a redesign, at which point we migrate them to the new stack.
WordPress Clients — Highest Priority
Migrate to Kinsta
Migrate all WordPress sites from the self-managed VPS to Kinsta managed WordPress hosting. Eliminates SSL chaos and server fires without touching the client experience. Kinsta offers free migrations for agency plans. Target: complete within 90 days.
Next.js + Payload Clients
Migrate to Vercel + Railway
Migrate these sites from the self-managed VPS to Vercel (frontend) and Railway (database). Both are managed platforms that handle SSL and deployment automatically. Lower volume — migrate over 60–90 days.
New Clients Going Forward
All new clients are built on the new stack from day one: Manus + GitHub + Cloudflare Pages. No exceptions for standard trades company websites. The only reason to deviate is if a client has a genuinely complex technical requirement (e-commerce, member portal, custom API integration) that requires a server-side solution.
Migration Priority Order
Priority
Group
Action
Target Timeline
1 — Immediate
New clients
Build on new stack from day one
Now
2 — High
WordPress on VPS
Migrate to Kinsta managed hosting
Within 90 days
3 — Medium
Next.js + Payload on VPS
Migrate to Vercel + Railway
Within 90 days
4 — Low
Duda clients
Migrate at renewal or redesign request
Ongoing
Operations
QA Checklist
Interactive pre-launch checklist. Click each item to check it off. Progress is tracked below.
How to use this checklist
Click any item to mark it as complete. Your progress is tracked in the bar above each section. Do not launch until all items are checked. Refresh the page to reset the checklist for a new build.
Code Quality
0%
HTML validates with zero errors and zero warnings at validator.w3.org
No inline styles anywhere in the HTML
All CSS in a single external stylesheet
All JavaScript in a single external file with defer attribute
CSS custom properties defined for all colors, fonts, and spacing
No unused CSS rules
No console errors in browser developer tools
No JavaScript frameworks or build tool artifacts
Performance
0%
PageSpeed Insights score: 100 on desktop
PageSpeed Insights score: 100 on mobile
All images in WebP format
All images have explicit width and height attributes
Hero image uses loading="eager" and fetchpriority="high"
All other images use loading="lazy"
No render-blocking resources
Google Fonts loaded with preconnect and display=swap
Accessibility
0%
WAVE WebAIM: zero errors
Every image has appropriate alt text
One <h1> per page, logical heading hierarchy
All form fields have visible <label> elements
All color combinations pass WCAG AA contrast (4.5:1 for normal text)
All interactive elements are keyboard-navigable
Skip-to-content link present on every page
<html lang="en"> on every page
SEO & AI Friendliness
0%
Unique title tag on every page (under 60 characters)
Unique meta description on every page (150–160 characters)
Open Graph tags on every page
Canonical tag on every page
JSON-LD LocalBusiness schema on every page
sitemap.xml present and valid
robots.txt present and correct
llms.txt present with complete business information
AI Friendliness audit: Pass
Functionality & Content
0%
All navigation links work correctly
Mobile hamburger menu opens and closes correctly
Contact form submits successfully (test with a real submission)
Contact form shows success message after submission
Phone number is a tap-to-call link on mobile
No "Lorem ipsum" placeholder text anywhere
All business information is accurate (name, phone, address, hours)
Copyright year is current
Privacy Policy and Terms of Service pages exist
Site is live on the client's domain with https:// (padlock visible)
Site added to UptimeRobot monitoring
Go-live email sent to client with Quarterback introduction
Team & Roles
Org Model
The five-track structure that replaces the old specialist chain. Each track has its own people, accountability, and handoff points.
The core insight
The old model blurred five distinct tracks together into a single chain of specialists, which is why everything felt tangled. Separating them cleanly is the unlock. Revenue no longer scales linearly with headcount — it scales with systems.
Track 1 — Sales & Business Development
The sales function exists to bring new clients in the door and introduce them to the right people. In the near term this is primarily the owner, supported by a part-time or fractional BD person as volume grows. Sales ends at the signed contract and the introduction to Onboarding — it does not manage the project, stay on the account, or get pulled into fulfillment problems. Clean separation here protects the owner’s time and keeps the sales motion moving. The referral engine is the most important sales asset: every client who has a great experience with their Quarterback is a potential referral source.
Track 2 — Onboarding & Fulfillment
The current chain — PM coordinates with content writer, who coordinates with designer, who coordinates with dev team, who coordinates with head developer for go-live — is a relay race where the baton gets dropped at every exchange. The new model collapses this entire chain into a single role: the Onboarding & Fulfillment Specialist. This person takes a client from signed contract to go-live, handling every step of the build process using AI tools as their execution engine.
The Onboarding Specialist’s job ends at go-live. Once the site is live, forms are working, SSL is confirmed, and the domain is resolving correctly, the account is handed off to the appropriate Client Success Quarterback. This handoff should be a formal, documented moment — a structured transition call or email that introduces the client to their Quarterback and sets expectations for the ongoing relationship.
Track 3 — Client Success Quarterbacks
This is the heart of the ongoing client relationship. Not all clients need the same quarterback. There are two tiers — see the Quarterbacks page for full detail on each tier, the graduation model, and the quarterback identity concept.
Track 4 — Product Owners (Internal Centers of Excellence)
Product Owners are not client-facing roles. They do not manage accounts or attend client calls. What they own is the quality and methodology of a specific service across every client in the business. This is the structural answer to the problem of nobody owning on-page SEO, nobody holding the offshore team accountable, and quality being inconsistent because there is no single standard.
Product Owner
What They Own
Current Candidate
SEO Product Owner
Keyword strategy, on-page standards, technical SEO checklists, offshore link-building accountability
Hosting platform, SSL governance, domain renewals, site health monitoring, on-call contractor relationship
Current head developer
AI Services Product Owner
Automation stack, GoHighLevel config, n8n/Make workflows, new AI product development, internal training
Owner (near term), dedicated hire as AI revenue grows
Track 5 — Technical Infrastructure & Hosting
This track is currently causing the most operational pain. The root cause: approximately 286 client sites across three different technology stacks (Duda, WordPress, Next.js + Payload) on self-managed VPS infrastructure. Self-managed VPS hosting requires a dedicated systems administrator to be maintained safely at scale. The goal is to get out of the infrastructure management business while keeping the hosting revenue. The platform strategy in the Tech Stack section resolves this entirely.
Team & Roles
Client Success Quarterbacks
The ongoing client relationship role — two tiers, a graduation model, and a visible identity system.
The Quarterback is not a middleman
A Quarterback does not coordinate between the client and someone else doing the work. They are the strategist, the executor, and the relationship owner all in one. The client calls them. They solve it.
Tier A — The Foundation Quarterback
Tier A Quarterbacks manage clients who are not doing active marketing — website-only clients, AI services clients, automation clients, and clients simply maintaining their digital presence. Their core competencies are relationship management, account health, basic website support, and AI tool fluency.
When something breaks on a client’s website, the Tier A Quarterback is the first responder. Because the platform strategy is designed to minimize infrastructure chaos, most issues they encounter will be content changes, form updates, page additions, or minor design tweaks — all of which an AI-fluent generalist can handle using Manus. For anything genuinely technical, they escalate to the Tech Product Owner.
The Tier A Quarterback does not need a marketing background. They need to be organized, warm, responsive, and genuinely good at making clients feel taken care of. Each Tier A Quarterback manages a pod of roughly 20–30 clients, depending on service complexity.
Tier B — The Marketing Pedigree Quarterback
Tier B Quarterbacks manage clients who are actively investing in marketing — SEO, paid media, content, or some combination. These clients have more at stake, more questions, and more need for strategic guidance. The Tier B Quarterback is not a middleman — they are the strategist, the executor, and the relationship owner all in one. They are on calls directly with the client and carry the strategy personally.
Their core competencies are paid media management (primarily Google Ads, Meta as secondary), SEO strategy and on-page execution, performance reporting, and client communication. They use AI tools to handle execution-heavy work — AI-assisted keyword research, AI-generated content drafts, automated reporting dashboards — so their time is spent on strategy and relationship rather than manual task execution. Each Tier B Quarterback manages a smaller pod of roughly 10–15 clients.
Tier A — Foundation
Tier B — Marketing Pedigree
Client type
Website-only, AI services, maintenance
Active marketing clients (SEO, paid media)
Pod size
20–30 clients
10–15 clients
Core skill
Relationship management, AI tool fluency
Paid media, SEO strategy, performance reporting
Marketing background?
Not required
Required
Revenue per client
Lower (hosting + maintenance)
Higher (marketing retainer)
The Graduation Model
Clients do not stay in one tier forever. A website-only client who decides to invest in SEO and Google Ads graduates from a Tier A to a Tier B Quarterback. This transition is framed to the client not as a handoff but as a promotion — they are moving to a specialist who is specifically equipped to help them grow. Done well, this graduation moment is also a natural upsell conversation. The Tier A Quarterback becomes a feeder for Tier B revenue without any additional sales effort.
The Quarterback Identity Concept
Trades business owners are relationship-driven buyers. They want to know who they are working with, what that person is good at, and why they should trust them. Consider giving each Quarterback a visible identity: a specialty label, a short bio, and optionally a CliftonStrengths or similar profile. A Quarterback who has a name, a face, and a stated specialty (“I work specifically with HVAC and plumbing companies on their Google presence”) is not just a vendor — they are a person. That distinction matters enormously in client retention.
This could manifest as a simple profile on your website, a personal introduction video sent at onboarding, or a physical card mailed to new clients. The investment is small; the relationship signal is large.
Current team assessment
Sara is best suited to internal marketing or a Tier A role rather than Tier B. The stronger paid media person is a Paid Media Product Owner candidate. The developer’s assistant — with AI tools and proper SOPs — could become the first Onboarding Specialist. The head developer is the Tech Product Owner.
MOBILE · OVERVIEW
Mobile SOP: World-Class Mobile UI/UX
Every site we build must feel native on a phone. This SOP defines the non-negotiable standards for mobile layout, interaction, and performance that Manus must apply to every build without exception.
Applies To
Every client website, every page, every component
Viewport Target
390px (iPhone 14 Pro) as the primary mobile reference
Secondary Target
768px (iPad Mini) for tablet breakpoint
Pass Criteria
No horizontal scroll, no invisible text, no broken layouts, no click-to-load barriers
Why Mobile Is Not an Afterthought
More than 60% of local service business website traffic arrives on a mobile device. A site that looks great on desktop but breaks on mobile is not a finished site. Every layout decision, every component, every interaction must be designed mobile-first and then expanded for desktop. The standard is not "it works on mobile" - the standard is "it feels like a native app on mobile."
The Mobile-First Design Rule
Write CSS for the 390px viewport first. Use min-width media queries to layer in desktop styles on top. Never write desktop styles first and then try to override them for mobile. When Manus receives a build prompt, the mobile layout must be explicitly designed, not derived by accident from desktop CSS shrinking down.
The Most Common Mobile Failures
Horizontal scroll caused by a fixed-width element. Invisible text because a color was hardcoded instead of using a CSS variable. A map or video that requires a click to load (adds friction on mobile). Navigation links that are invisible because a CSS nth-child stagger animation broke when the number of nav items changed. These are all preventable with the standards in this SOP.
Core Mobile Layout Rules
These rules apply to every page of every build. They are not optional and are not subject to client design preferences.
Rule
Implementation
Common Failure
No horizontal scroll
Set overflow-x: hidden on body. Audit every fixed-width element.
A hero image, stats bar, or table wider than the viewport
Minimum tap target 44x44px
All buttons, nav links, and CTA elements must be at least 44px tall with adequate padding
Nav links at 28px height, impossible to tap accurately on a phone
Readable font sizes
Body text minimum 16px on mobile. Never below 14px for any visible text.
Fine print, captions, or eyebrow labels at 10-11px - unreadable without zooming
Full-width CTAs
Primary CTA buttons must be width: 100% or at minimum min-width: 280px on mobile
Desktop-sized button (200px wide) centered on a 390px screen looks weak and is hard to tap
Single-column layouts
Any multi-column desktop grid must collapse to a single column at 768px or below
Two-column grid at 390px where each column is 195px - text wraps badly and images are tiny
Auto-loading maps and media
Maps and iframes must load automatically on scroll into view (IntersectionObserver). Never require a click to reveal.
A "Click to load map" placeholder that adds friction and looks unfinished
Sticky call bar
A fixed bottom bar with the phone number and a "Call Now" CTA must be present on every page on mobile
The most important conversion action (calling) is buried in the footer
Mobile Navigation Standards
The mobile navigation is the most-used UI element on a mobile site. It must work flawlessly on every page, including interior pages, service pages, and any page added in the future. These standards are non-negotiable.
Standard
How to Implement It
JS-driven stagger animation
Never use CSS nth-child selectors to stagger nav link entrance animations. The child count changes when sub-links are added. Instead, use JavaScript to assign transition-delay to each link in order at open time. This is resilient to any number of nav items.
Sub-links styled separately
Service sub-links inside the mobile nav must use a dedicated CSS class (e.g., .mobile-nav-sub) with smaller font size, reduced opacity, and indented padding. They must never inherit the same stagger delay as top-level links.
Logo visible in open nav
When the nav panel is open, the logo must be visible. Check for color conflicts - a white logo on a white nav background is invisible. Use a CSS variable for the nav background so it is always consistent.
Close on outside tap
Tapping outside the open nav panel must close it. Add a click listener to the overlay element that calls the close function.
Active state on current page
The nav link for the current page must have an active class applied via JavaScript on page load, based on window.location.pathname.
Mobile Performance Requirements
A mobile site that scores below 90 on Google PageSpeed Insights (mobile) is not a finished site. The following are the primary performance levers for mobile.
Lever
Target
Implementation
Image format
All images in WebP
Convert all JPG/PNG assets to WebP before upload. Use manus-upload-file --webdev to get CDN URLs.
Image lazy loading
All below-fold images
Add loading="lazy" to every <img> tag that is not in the hero section.
Hero image preload
LCP under 2.5s
Add <link rel="preload" as="image"> for the hero image in the <head>.
Font loading
No layout shift
Self-host fonts or use font-display: swap. Add preconnect to Google Fonts if used.
CSS delivery
No render-blocking CSS
Inline critical CSS in <style> in the <head>. Load non-critical CSS asynchronously.
JS defer
No render-blocking JS
All <script> tags must use defer attribute. No inline scripts in the <body> above the fold.
MOBILE · COMPONENT STANDARDS
Mobile Component Standards
Component-by-component specifications for world-class mobile UI/UX. Each section defines the required behavior, the CSS approach, and the most common failure mode to watch for.
Navigation
The mobile nav panel slides in from the right (or left) and covers the full viewport height. It must animate open and closed smoothly, and every link must be visible and tappable immediately after opening.
Spec
Value
Panel width
85vw, max 340px
Background
Dark (matches site header color, e.g., #111)
Top-level link height
Minimum 52px (large tap target)
Sub-link height
Minimum 40px, 0.6 opacity, 0.875rem font size, indented 1rem
Stagger animation
JS-driven: 60ms delay per link, starting from 80ms. Never CSS nth-child.
Close trigger
X button, overlay tap, and Escape key
Active link indicator
Left border 3px solid red, or background highlight
Why JS-Driven Stagger Is Required
CSS nth-child stagger rules break the moment the number of nav items changes. When service sub-links are added, the nth-child selectors no longer match the correct elements, and links appear invisible (stuck at opacity: 0). The JS approach assigns transition-delay at open time based on the actual DOM order, so it works correctly regardless of how many items exist.
Hero Section
The hero is the first thing a mobile visitor sees. It must load fast, display the correct image, and present the headline and CTA without requiring any scrolling.
Spec
Value
Height
100svh (small viewport height - accounts for mobile browser chrome). Fallback: 100vh.
Image
WebP format, uploaded to CDN. Preloaded with <link rel="preload">. Never a local file.
Overlay
Dark gradient overlay (e.g., linear-gradient(to bottom, rgba(0,0,0,0.4), rgba(0,0,0,0.6))) to ensure text is always readable regardless of image brightness.
Headline font size
clamp(2.25rem, 10vw, 3.5rem) - scales with viewport, never overflows
CTA button
Full width on mobile (width: 100%), minimum 52px height
Text color
Always white on dark overlay. Never use dark text on a hero image without a guaranteed light background.
Testimonials
On desktop, testimonials display as a 2- or 3-column grid. On mobile, they must become a horizontal swipe carousel. Stacking 3 testimonials vertically on a phone creates a long, tedious scroll. The carousel pattern is the industry standard for this component on mobile.
Spec
Value
Mobile layout
Horizontal scroll container with scroll-snap-type: x mandatory
Card width
flex: 0 0 calc(100% - 2.5rem) - one card fills the viewport with the next card peeking in
Required. 3 dots below the carousel, red active state, tappable to jump to card. Hidden on desktop.
Dot JS
Listen to scroll event on the grid container. Calculate active index from scrollLeft / cardWidth. Update dot active class.
Desktop layout
Unchanged - CSS grid, no carousel behavior
Gallery
The gallery is one of the highest-traffic sections on a local service business site. On mobile, the category tabs must be accessible without scrolling, and the photo grid must feel like a native photo app - full-bleed, tight grid, instant category switching.
Spec
Value
Category tab bar
Sticky below the nav bar (position: sticky; top: 72px). Horizontal scroll with no scrollbar. Background matches site dark color.
Tab style (mobile)
Underline indicator, not pill buttons. border-bottom: 2px solid var(--red) on active. Transparent background. Matches native app tab bar conventions.
Photo grid
Full-bleed (no side padding). 2-column square grid. 2px gutters. aspect-ratio: 1/1 on each item.
Grid gap
2px - tight, Instagram-style
Lightbox
Full-screen on mobile. Swipe left/right to navigate. Close button 44x44px minimum.
Desktop layout
4-column grid with 0.625rem gaps. Pill-style tabs centered. Unchanged.
Service Cards / Feature Grid
Any grid of service cards, feature highlights, or icon+text blocks must collapse gracefully on mobile.
Desktop Layout
Mobile Layout
Notes
3-column grid
Single column, full width
Cards stack vertically with 1.5rem gap
4-column grid
2-column grid
Only if cards are simple (icon + short label). Otherwise single column.
Horizontal card (image left, text right)
Vertical card (image top, text below)
Use flex-direction: column at mobile breakpoint
Icon + heading + paragraph
Same, but icon centered, text left-aligned
Avoid centering body text on mobile - it is harder to read
FAQ / Accordion
FAQs must always use an accordion pattern on mobile. Never display all answers expanded on mobile - it creates an overwhelming wall of text. The accordion tap target must be at least 52px tall.
Spec
Value
Question tap target
Minimum 52px height, full width
Answer reveal
CSS max-height transition from 0 to auto (use a large max-height value like 600px as the expanded state)
Chevron icon
Rotates 180 degrees when open. Use CSS transform: rotate(180deg) on the open state.
Only one open at a time
Optional but preferred. Closing the previous item when a new one opens reduces cognitive load.
Forms on mobile must be designed for thumb input. Fields must be large enough to tap, labels must be visible, and the submit button must be full width.
Spec
Value
Input field height
Minimum 52px
Font size inside inputs
Minimum 16px - prevents iOS from auto-zooming the viewport on focus
Label position
Above the field, never inside (placeholder text disappears on focus)
Submit button
Full width (width: 100%), minimum 52px height
Input type
Use correct type attributes: type="tel" for phone, type="email" for email. Triggers the correct keyboard on iOS/Android.
Error states
Inline error messages below each field. Red border on invalid field. Never use alert() dialogs.
Maps
Maps must load automatically when scrolled into view. Never require a user to click a placeholder to reveal the map. Use IntersectionObserver to trigger the iframe src assignment when the map container enters the viewport.
// Auto-load map on scroll into view
const mapContainer = document.querySelector('.map-container');
if (mapContainer) {
const observer = new IntersectionObserver((entries) => {
entries.forEach(entry => {
if (entry.isIntersecting) {
const iframe = mapContainer.querySelector('iframe[data-src]');
if (iframe) {
iframe.src = iframe.dataset.src;
iframe.removeAttribute('data-src');
}
observer.unobserve(entry.target);
}
});
}, { threshold: 0.1 });
observer.observe(mapContainer);
}
Sticky Call Bar
Every page on every site must have a sticky call bar fixed to the bottom of the mobile viewport. This is the single highest-converting element on a local service business mobile site. It must be present on every page, including interior pages, service pages, and the contact page.
56px on mobile, hidden on desktop (display: none above 768px)
Content
Phone icon + phone number on the left. "Call Now" CTA button on the right.
Body padding
Add padding-bottom: 56px to body on mobile to prevent the bar from covering content
Background
Dark background matching the site header. High contrast.
Phone link
<a href="tel:+1XXXXXXXXXX"> - the entire bar must be a tap target
Mobile QA Checklist
Before marking any build ready for client review, verify every item in this checklist at 390px viewport width.
Check
Pass Criteria
No horizontal scroll
Swipe left on every page - no content extends beyond the viewport edge
Nav opens and all links visible
Tap hamburger - all nav links animate in and are fully visible. Sub-links are visible at reduced opacity.
Nav closes on outside tap
Tap the overlay - nav closes
Active nav link highlighted
Current page link has active state
Hero image loads fast
Hero image visible within 2 seconds on a simulated 4G connection (Chrome DevTools throttling)
All text readable without zooming
No text below 14px. Body text 16px minimum.
All tap targets 44px+
No button or link smaller than 44x44px
CTA buttons full width
Primary CTAs span the full content width on mobile
Testimonials swipe carousel
Cards swipe horizontally. Dots update on swipe. Dots tappable.
Gallery tabs sticky
Scroll down in gallery - tab bar stays visible below the nav
Gallery grid full-bleed
Photos extend edge to edge. 2-column square grid. 2px gutters.
Map auto-loads
Scroll to map section - map loads automatically without any click
Sticky call bar visible
Fixed bar at bottom of screen on every page. Does not cover content.
Form inputs 16px+
Tap a form field - iOS does not zoom the viewport
PageSpeed mobile score
90 or above on Google PageSpeed Insights (mobile)
Play-by-Play
Play-by-Play
Every step of the website build process — from signed contract to live site — broken into individual plays with detailed instructions for each.
How to use the Play-by-Play
Each play is a self-contained unit of work with a specific input, a specific output, and detailed step-by-step instructions. When a play feels clunky or produces inconsistent results, document the friction in the play itself and refine the instructions. Over time, each play becomes more precise and the overall process runs faster.
Plays 4, 5, and 6 are not optional. Skipping them is how mobile nav bugs, missing font weights, and contrast regressions reach the client. Each QA play has a specific automated script — run the script, read the output, fix what it finds, run it again. Do not advance to the next play until the current play's output criteria are met.
Play-by-Play · Play 1
Play 1: Kickoff Call
Collect everything needed to build the site in a single 45-minute call. Leave with a completed brief — not a list of follow-up questions.
Input
Output
Who
Time
Signed contract, client contact info
Completed client brief (all fields filled)
Onboarding Specialist
45–60 min
Before the Call
Open the Client Brief Template (see the Client Brief page in this playbook). Create a copy named after the client. Fill in every field you already know from the contract: business name, address, phone number, and any services listed in the contract. This saves time on the call and signals professionalism.
Send the client a calendar invite with a Zoom or Google Meet link. Include a one-sentence note: "This is our onboarding call where we'll collect everything needed to build your website. The call takes about 45 minutes." Do not send a pre-call questionnaire — clients rarely complete them and it creates a second round of follow-up.
During the Call — Required Information
Work through the brief template section by section. Do not improvise the order — the template is sequenced so that each answer informs the next question. The sections and what to capture in each:
Section
What to Capture
Common Gaps
Business basics
Legal business name, DBA (if different), physical address, phone number, email, website URL (if existing), year established
Clients often give a cell number — confirm this is the number they want on the site
Service area
Cities and counties served, whether they travel outside the area, any areas they explicitly do not serve
Ask "Is there anywhere you won't go?" — this surfaces important exclusions
Services offered
Complete list of services, any specialties or certifications, services they want to emphasize vs. de-emphasize
Ask "What's the job you most want the phone to ring for?" — this shapes the homepage hero
Business hours
Hours for each day of the week, whether they take emergency/after-hours calls, holiday closures
Many clients say "by appointment" — clarify if they want that on the site
Unique selling points
Why do clients choose them over competitors? Years in business, certifications, guarantees, awards, family-owned, locally owned
Ask "What do your best customers say about you?" — this surfaces authentic differentiators
Google reviews
Google Business Profile URL, current star rating, number of reviews
Ask them to share their screen and navigate to their Google Business Profile so you can capture the exact URL
Ask for each platform individually — clients often forget they have profiles
Photos
Project photos (before/after, finished work), team photos, logo file
If they have no photos, note this — stock photos will be used and client should be told
Design direction sliders
Six slider scores (1–5) that define the visual personality of the site. Record a number for each axis: Classic ↔ Modern, Light ↔ Dark, Simple ↔ Layered, Friendly ↔ Authoritative, Economical ↔ Premium, Gritty ↔ Polished. A score of 1 means far left; a score of 5 means far right.
Ask each axis as a quick question: “On a scale of 1 to 5, where 1 is Classic and 5 is Modern, where does your brand sit?” Most clients answer instantly. These six numbers give Manus a complete design profile — no reference sites required. Reference sites are optional and additive; if the client mentions a site they love, note the URL, but never make the call dependent on finding one.
Domain
Do they have a domain? Who is the registrar? Do they have login access?
Many clients have domains they can't access — flag this early so it doesn't block launch
Content preferences
Tone (professional, friendly, authoritative), any words or phrases they always use, anything they never want on the site
Ask "Is there anything you absolutely don't want us to say?" — this prevents awkward revisions
After the Call
Within 30 minutes of ending the call, complete the brief with any notes you took during the conversation. Send the client a brief confirmation email: "Thanks for your time today. We have everything we need to build your site. You'll receive a preview link within [X] business days." Do not promise a specific date unless you are certain of your schedule.
If any required field is still blank after the call, send a single follow-up email listing only the missing items. Do not call — email creates a paper trail and gives the client time to gather the information. If you have not received the missing information within 48 hours, send one reminder. After that, proceed with best-available information and note the assumption in the brief.
Play 1 complete when
Every field in the Client Brief Template is filled. No field says "TBD" or "ask client." All six design direction slider scores (1–5) have been recorded. Photos have been received or a stock-photo decision has been made. The brief is saved and ready to hand to Manus for scraping.
PLAY-BY-PLAY · PLAY 1B
Play 1B: Content Scraping & Site Inventory
Before writing a single line of new code, extract everything from the client’s existing site. This play produces the raw material that feeds the Brief (Play 2) and eliminates the risk of losing content during the rebuild.
Input
Client’s existing website URL
Output
Full site inventory: all copy, images, logos, custom integrations, and SEO data
Who Runs It
Manus AI (directed by Onboarding Specialist)
Time
30–60 minutes
Pass Criteria
Every page inventoried; all assets downloaded; SEO snapshot captured
Why This Play Exists
Rebuilds fail when content gets lost in translation. The client assumes you have it; you assume they’ll send it. This play closes that gap entirely by systematically pulling everything from the live site before work begins. It also captures the current SEO baseline so you can verify the rebuild doesn’t regress on rankings.
Step 1: Crawl the Full Site Structure
Paste the following prompt into Manus to begin the inventory:
Please do a complete content inventory of [CLIENT WEBSITE URL].
For each page, capture:
1. Page URL and title tag
2. Meta description
3. H1 and all subheadings (H2, H3)
4. All body copy (full text, not truncated)
5. All image URLs and alt text
6. Any embedded forms, iframes, or third-party integrations (maps, booking widgets, chat, etc.)
7. Schema markup (if any)
8. Internal links
Then:
- Download all images, logos, and icons to an /assets folder
- Pull the XML sitemap (if available at /sitemap.xml)
- Check robots.txt
- Note any pages that return 404 or redirect
Save everything to a structured inventory file at /inventory/site-inventory.md
Step 2: SEO Baseline Snapshot
After the crawl, capture the current SEO state so you have a before/after comparison after launch:
For [CLIENT WEBSITE URL], capture the current SEO baseline:
1. All page titles and meta descriptions (full text)
2. Canonical tags on each page
3. Open Graph tags (og:title, og:description, og:image) on each page
4. Any structured data / JSON-LD schema blocks
5. Heading hierarchy (H1 → H2 → H3) on each page
6. Image count and whether each has alt text
7. Internal link structure (which pages link to which)
8. Page load speed (run a quick Lighthouse check on the homepage)
9. Mobile-friendliness (note any obvious mobile issues)
Save as /inventory/seo-baseline.md
Step 3: Review the Inventory
Before moving to Play 2, the Onboarding Specialist must review the inventory file and flag:
Any pages that exist on the live site but were not captured (check nav, footer, and sitemap)
Images that downloaded at low resolution (flag for client to provide originals)
Third-party integrations that will need to be re-embedded (booking systems, chat widgets, payment forms)
Any content that appears outdated and should be updated in the rebuild
Custom fonts or brand assets that need to be sourced
Step 4: Organize Assets
Create a clean asset folder structure that will carry forward into the build:
/inventory/
site-inventory.md ← full page-by-page content
seo-baseline.md ← SEO snapshot
/assets/
/images/ ← all downloaded images
/logos/ ← all logo variants
/icons/ ← any icon files
/integrations.md ← list of all third-party embeds with embed codes
Common Failure Mode: Manus scrapes the homepage but misses interior pages. Always cross-reference the sitemap and the site’s navigation menu to ensure every page is captured. If the site has no sitemap, manually list all pages visible in the nav and footer and ask Manus to scrape each one individually.
Pass Criteria
Every page in the site navigation has been inventoried
All images and logos have been downloaded to /assets/images/ and /assets/logos/
A photo inventory table has been compiled listing every image with a description and a PM “Use / Request better / Skip” column
Brand colors have been extracted from the logo file using Manus (exact hex codes confirmed)
All third-party integrations have been identified and documented
SEO baseline has been captured (titles, meta descriptions, schema)
Inventory file reviewed and flagged items noted for the Brief Prep
Brand Color Extraction: After downloading the logo, ask Manus: “Extract the exact hex color codes from this logo file: [logo filename]. List every distinct color with its hex code.” Record these in the Brief Prep. Never guess brand colors — always extract from the actual logo file.
Get domain registrar access, DNS credentials, and hosting details documented before the build starts. Waiting until launch day to discover the client doesn’t know their GoDaddy password is a project killer.
Input
Client contact (phone or email)
Output
Domain registrar access confirmed, DNS records documented, hosting credentials on file
Who Runs It
Onboarding Specialist
Time
15–30 minutes
Pass Criteria
Onboarding Specialist can log into the domain registrar and view DNS records
Why This Play Exists
DNS changes at launch require registrar access. If the client can’t find their login, launch day turns into a 3-day delay. Capturing this information during onboarding — when the client is engaged and responsive — eliminates that risk entirely.
Step 1: Domain Registrar Checklist
Ask the client to provide or confirm access to each of the following:
Item
Where to Find It
Why We Need It
Domain registrar name
GoDaddy, Namecheap, Google Domains, etc.
Know where to make DNS changes
Registrar login credentials
Client email + password (or invite us as user)
Access to make DNS changes at launch
Domain expiration date
Registrar dashboard
Prevent domain expiry during project
Current DNS records
Registrar DNS management panel
Document before making any changes
Current hosting provider
Where the old site is hosted
Know what to point away from
Step 2: Document Current DNS Records
Before touching anything, take a screenshot of the current DNS records and save them to the project folder. This is your rollback reference if anything goes wrong at launch.
# Records to document:
A record (root domain → IP address)
CNAME record (www → root or hosting)
MX records (email routing — DO NOT change these)
TXT records (SPF, DKIM, Google verification, etc.)
Any existing CNAME records for subdomains
Critical: Never modify MX records. These control email delivery. Changing them will break the client’s email. Only modify the A record and www CNAME at launch.
Step 3: Cloudflare Pages DNS Setup (at Launch)
When the site is ready to go live, the DNS changes needed for Cloudflare Pages are:
# Add these records in the registrar:
Type: CNAME
Name: www
Value: [project-name].pages.dev
Type: CNAME (or A record if registrar doesn't support CNAME flattening)
Name: @ (root)
Value: [project-name].pages.dev
# Then in Cloudflare Pages dashboard:
Settings → Custom domains → Add custom domain → [clientdomain.com]
Pass Criteria
Domain registrar name and login confirmed
Domain expiration date checked (not expiring within 90 days)
Current DNS records documented and saved to project folder
Current hosting provider identified
Onboarding Specialist can successfully log into the registrar
Before the build begins, run the Dotcom Design SEO Strategy System to generate the keyword-city matrix. This determines exactly which SEO keyword pages to build and ensures every page targets a real search opportunity.
Input
Client website URL (from Play 1B scrape)
Output
Keyword-city matrix with 30–40 city+service combinations; SEO strategy site URL to share with client
Who Runs It
Onboarding Specialist (in the SEO Strategy System task)
Time
5–10 minutes
Pass Criteria
Strategy site is live at seo-strategy.dotcomdesign.com/[clientdomain]; keyword-city matrix is confirmed and ready to paste into the Build Prompt
Why This Play Exists
SEO keyword pages are one of the highest-value deliverables in every build. A masonry contractor serving 48 cities with 15 services has hundreds of possible city+service combinations — but not all of them have real search volume. Running the SEO Strategy System before the build ensures Manus builds the right 30–40 pages, not a random selection. It also produces a client-facing strategy document that demonstrates the value of the work.
How to Run This Play
This play runs in a separate, persistent Manus task called the SEO Strategy System. That task has GitHub authenticated and the strategy repo already cloned. Do not run this play in the same task as the website build.
Open the SEO Strategy System Manus task (keep it bookmarked — it is a persistent task)
Copy the generated prompt from the form and paste it into the SEO Strategy System task
Manus will run keyword research via SEMrush, build the keyword-city matrix, and deploy the strategy site automatically
Copy the live strategy URL (e.g., seo-strategy.dotcomdesign.com/markusonconstruction.com)
Paste the strategy URL into the Build Prompt (Section 7 — SEO Keyword Pages) so Manus can reference the matrix during the build
What the Matrix Tells Manus
The keyword-city matrix is a table of city+service combinations ranked by strategic priority. For each combination, Manus builds one SEO keyword page. The standard build includes 30–40 keyword pages selected from the matrix. Manus picks the combinations automatically based on the matrix — the PM does not need to select them individually.
Standard keyword page count per build: 30–40. This range keeps the build manageable while providing meaningful SEO coverage. Do not build fewer than 30 (insufficient coverage) or more than 40 at launch (diminishing returns without a content maintenance plan). Additional pages can be added in future maintenance cycles.
How SEO Pages Integrate Into the Site
SEO keyword pages are not standalone — they are woven into the fabric of the site. The Build Prompt instructs Manus to:
Add a “Cities We Serve” section at the bottom of each service page, linking to the relevant keyword pages
Add an “Areas We Serve” section in the footer linking to the top-priority city pages
Create a /service-areas page that links to all keyword pages for crawlability
Include internal links from blog posts to relevant keyword pages (when a blog exists)
Pass Criteria
SEO Strategy System task has been run for this client
Strategy site is live at seo-strategy.dotcomdesign.com/[clientdomain]
Keyword-city matrix has been reviewed and confirmed
Strategy URL has been added to the Build Prompt (Section 7)
Translate the completed client brief — pre-filled by Manus from the scrape — into a confirmed build prompt. Review scraped data, confirm services and sitemap, select design direction, then submit.
Input
Output
Who
Time
Completed client brief
Formatted Manus build prompt, ready to submit
Onboarding Specialist
15–30 min
The Anatomy of a Good Build Prompt
A Manus build prompt has ten required sections. Each section serves a specific purpose — omitting any section forces Manus to make assumptions, which produces inconsistencies that require revision rounds. The Build Prompt Template page in this playbook contains the full template with fill-in fields. The ten sections are:
Section
Purpose
What Happens If Missing
1. Project context
Tells Manus what kind of business this is, who the audience is, and what the site needs to accomplish
Manus writes generic copy that doesn’t reflect the client’s voice or market
2. Business information
All factual content: name, address, phone, hours, services, service area, reviews, social links
Placeholder text appears in the built site; revision round required
3. Brand assets
Logo file path, exact hex color codes (extracted from logo), photo file paths
Manus uses default colors and stock photos; visual identity is generic
4. Design direction
Six slider scores (1–5) from the KO call: Classic/Modern, Light/Dark, Simple/Layered, Friendly/Authoritative, Economical/Premium, Gritty/Polished. Optional reference site URL with usage instruction.
Manus makes arbitrary design decisions that may not match client expectations
5. Sitemap
Explicit list of every page to build, confirmed by PM after reviewing the scrape output
Manus may build extra pages or miss required pages
6. Page structure requirements
Section-by-section architecture for each page type (home, service, about, contact, SEO keyword, landing)
Manus invents page structures that are inconsistent across the site
7. SEO keyword pages
Link to the SEO Strategy site with the keyword-city matrix; Manus selects 30–40 combinations and builds one page per combination
Keyword pages are built without strategic targeting; wrong city+service combinations are prioritized
8. Content notes
Any copy direction, tone notes, tagline, things to avoid, special requirements (file upload, career section, etc.)
Manus writes in a generic tone; special requirements are missed
Manus may use CDN fonts, skip schema, or miss AI discoverability requirements
10. Quality requirements
Explicit audit targets: WAVE zero errors, PageSpeed 100 mobile AND desktop, W3C zero errors/warnings, AI Friendliness pass
Manus stops at a lower quality bar or skips audits entirely
Uploading Assets
Before submitting the prompt, upload all client assets (logo, photos) to the Manus task. Drag and drop files into the Manus chat window before typing the prompt. Name files descriptively before uploading: logo-color.png, photo-kitchen-remodel-1.jpg, photo-team.jpg. Manus will reference these files by name in the build. Assets should already be organized from Play 1B — copy them from the /assets/ folder directly.
If the client has no logo, note “No logo — use text-only logo treatment” in the prompt. If the client has no photos, note “No client photos — use high-quality stock photos of [specific subject matter].” Never leave the asset section blank.
Setting Design Direction
Design direction is driven by the six slider scores captured on the KO call — not by reference sites. Paste the scores directly into Section 4 of the Build Prompt: “Classic/Modern: 4, Light/Dark: 4, Simple/Layered: 3, Friendly/Authoritative: 4, Economical/Premium: 3, Gritty/Polished: 3.” If the client mentioned a site they liked during the KO call, add it as an optional reference with one of these instructions: Design inspiration only (loose feel), Mimic layout and visual rhythm (match section structure), or Match structure, adapt style (same blueprint, client’s brand skin). Reference sites are never required — the sliders are always sufficient.
Play 2 complete when
The Manus prompt is written using the Build Prompt Template. All ten sections are filled. All client assets are uploaded to the Manus task. Design direction sliders are included. SEO strategy URL is included in Section 7. The prompt is ready to submit — no further editing needed.
Play-by-Play · Play 3
Play 3: Site Build
Submit the build prompt to Manus and monitor the build. Know when to intervene and when to let it run.
Input
Output
Who
Time
Formatted Manus build prompt + uploaded assets
Complete site files in sandbox, deployed to preview URL
Manus AI (Specialist monitors)
2–4 hours
Submitting the Prompt
Paste the completed build prompt into Manus and submit. Do not add extra instructions or caveats at this stage — the prompt already contains everything Manus needs. After submitting, Manus will create a task plan and begin executing. You will see it working through phases: reading the reference site, building the HTML/CSS, deploying to Cloudflare Pages, running audits.
When to Intervene During the Build
The build is largely autonomous. Intervene only in these specific situations:
Situation
What to Do
Manus asks a clarifying question
Answer it directly and concisely. Do not add new requirements at this point.
Manus appears stuck on the same step for more than 10 minutes
Type "Please continue" or "What's blocking you?" to prompt it forward.
Manus reports it cannot access the reference site
Provide an alternative reference site URL or describe the desired layout in plain language.
Manus asks for login credentials to deploy
Do not provide credentials in chat. Instead, use the browser takeover feature to log in manually.
Manus reports the build is complete
Do not proceed to Play 4 yet — first confirm the preview URL is live and all pages load without errors.
What Manus Should Produce
At the end of Play 3, Manus should have produced: all HTML pages (one per page in the page list), a CSS file or inline styles, a JavaScript file for interactions, all images compressed to WebP format, a sitemap.xml, a robots.txt, a llms.txt, JSON-LD schema markup on every page, and a deployed preview URL on Cloudflare Pages or similar.
If any of these outputs are missing, ask Manus to produce them before advancing to Play 4. Do not advance to QA with an incomplete build.
Gallery Design Standards (mandatory)
1. Uniform grid heights. Always use CSS Grid with aspect-ratio: 4/3 on every gallery cell. Never use CSS columns (masonry layout) — it produces uneven column heights which look unprofessional. Implementation: .gallery-grid { display:grid; grid-template-columns: repeat(4,1fr); gap: 0.625rem; } and .gallery-item { aspect-ratio: 4/3; overflow:hidden; } and .gallery-item img { width:100%; height:100%; object-fit:cover; }.
2. Section separation. Before placing any new section, check the background color of the section directly above and below it. If two adjacent sections share the same background color, they will visually merge into one undifferentiated block. Fix by either (a) using a slightly different background value (e.g., #111111 vs #1a1a1a), or (b) adding a border-top and border-bottom in the brand accent color to create a deliberate visual break. This check is mandatory any time a new section is added.
Mobile-First Build Standards (mandatory)
1. Sticky call bar on every page. Every local service site must include a fixed bottom bar on mobile with a tap-to-call button. This is the single highest-ROI element on any local service site. CSS: .sticky-call-bar { display:none; position:fixed; bottom:0; left:0; right:0; z-index:9999; } and @media(max-width:767px){ .sticky-call-bar{display:block;} body{padding-bottom:56px;} }. HTML: <div class="sticky-call-bar"><a href="tel:+1XXXXXXXXXX">📞 Call Now</a></div>.
2. Touch targets minimum 44×44px. All buttons, nav links, and tap-to-call links must have a minimum height and width of 44px on mobile. Use min-height:44px; padding:.75rem 1rem; on all interactive elements. Never use font sizes below 16px on mobile — this prevents iOS auto-zoom on input focus.
3. Mobile nav must be tested by clicking. After building the mobile nav, always resize to 390px and click the hamburger button. The two most common bugs — wrong hamburger placement and invisible logo in the nav panel — are only visible when you actually interact with the nav. Scrolling through at mobile width is not sufficient.
4. CSS variable minification guard. If using a CSS minifier or build step, always verify that var(--custom-property) names are not corrupted. A common minification bug turns var(--nav-height) into var(- - nav - height) (spaces inserted around dashes). After minification, run: grep -o "var(- -[^)]*)" *.html — any result is a bug. Fix by replacing the broken pattern with the correct variable name.
5. Cloudflare Pages deployment — two-URL trap. Cloudflare Pages creates two distinct URL types: the production alias (projectname.pages.dev) and branch preview URLs (HASH.projectname.pages.dev or main.projectname.pages.dev). These are served from different deployments. The production alias only updates when you deploy to the branch set as "production branch" in the project settings. Always deploy with wrangler: CLOUDFLARE_API_TOKEN=TOKEN CLOUDFLARE_ACCOUNT_ID=ACCOUNT_ID CI=true npx wrangler@3 pages deploy /path/to/site --project-name=PROJECT_NAME --branch=main. After deploying, verify the production alias specifically (not the branch preview): curl -sL "https://projectname.pages.dev/" | wc -c must match wc -c index.html. See Play 7 for the full deployment verification checklist.
Play 3 complete when
All pages load at the preview URL without errors. All required files exist (HTML, CSS, JS, images, sitemap.xml, robots.txt, llms.txt). The preview URL is accessible from a browser — not just from the Manus sandbox.
Play-by-Play · Play 4
Play 4: Visual QA
Compare every page of the built site against the reference site at both mobile and desktop viewports. Document every discrepancy before touching any code.
Input
Output
Who
Time
Preview URL + reference site URL
Discrepancy list, all fixes applied and verified
Onboarding Specialist (reviews) + Manus (fixes)
30–60 min
Why Visual QA Comes Before Technical QA
Technical audits (axe, PageSpeed, W3C) measure code quality. They do not measure whether the site looks right. A site can score 100 on PageSpeed and still have the wrong hero image, missing sections, or invisible text. Visual QA must happen first because fixing visual issues sometimes requires structural HTML changes — and those changes can affect technical audit results. Doing technical QA first and then making structural changes means running the technical audits twice.
The Visual QA Process
Open the reference site and the preview site in separate browser tabs. Navigate to the same page on both. Take a screenshot of both at 1280px wide (desktop). Compare them side by side. Then resize to 390px wide (mobile) and compare again. Repeat for every page. Document every difference in a discrepancy list — do not fix anything yet. Complete the full comparison first, then fix everything in one pass.
What to Check on Every Page
Common Failure Mode
Header: logo visible, nav links correct, CTA button correct
Logo invisible (white text on white background in mobile nav)
Mobile (390px): hamburger at far right of nav bar
Hamburger missing margin-left: auto, sits next to logo
Mobile (390px): tap hamburger — logo fully visible in nav panel
Logo top line invisible (inline style="color:#fff" on white background)
Hero: correct image, correct H1 text, correct CTA
Generic stock photo instead of client-specific image
All body copy matches reference word-for-word
Truncated paragraphs, missing sections, placeholder text
Signature lines (e.g., "— The DTO Team") present and styled in gold italic
Signature invisible due to CSS specificity conflict
Stats bar: full-width dark background, all stats correct
Stats bar renders as a white box instead of full-width dark bar
Footer: all columns present, all links correct, phone number correct
Missing footer column, wrong phone number
Contact page: hours table complete, all days and times correct
Missing days, wrong hours
Gallery page: all images load, captions correct
Broken image paths, missing captions
Gallery grid: all rows are the same height — no column that is taller than the others
Using CSS columns (masonry) instead of CSS Grid with aspect-ratio. Fix: set display:grid; grid-template-columns: repeat(4,1fr) and aspect-ratio: 4/3 on every .gallery-item. Images use object-fit:cover; width:100%; height:100%.
Gallery section background is visually distinct from the section directly above and below it
Gallery section and adjacent section share the same background color, causing them to visually merge. Fix: give the gallery section a different background value (e.g., #111111 vs #1a1a1a) AND add a border-top: 4px solid var(--red) and border-bottom: 4px solid var(--red) to create a clear visual break.
Submitting Fixes to Manus
After completing the full comparison, submit all discrepancies to Manus in a single message. Format the message as a numbered list: "1. [Page] [Element] — [What's wrong] — [What it should be]." Manus will fix all items and redeploy. After the fix deployment, repeat the visual comparison on the changed pages to confirm all items are resolved.
Always check mobile nav by actually clicking it
The two most common mobile nav bugs — wrong hamburger placement and invisible logo — are only visible when you resize to mobile width AND click the hamburger button. Scrolling through the page at mobile width is not sufficient. You must interact with the nav to catch these bugs.
Always review in an Incognito / Private browser window
Your regular browser caches CSS, fonts, and images aggressively. If you review the preview URL in a normal window after Manus deploys a fix, you may be looking at a stale cached version — not the live update. This causes false positives: you report an issue that is already fixed, or you approve a version that has a bug the cache is hiding. Always open the preview URL in a fresh Incognito (Chrome) or Private (Safari/Firefox) window when reviewing after any deployment. If something still looks wrong after Manus confirms a fix is deployed, open a new Incognito window before reporting it again.
Play 4 complete when
Every page matches the reference at both 390px and 1280px. The mobile nav hamburger is at the far right. The mobile nav panel shows the full logo. All body copy is present and correct. No placeholder text remains. The discrepancy list is empty.
Play-by-Play · Play 5
Play 5: Technical QA
Run all four automated audits on the deployed preview URL. Zero violations required before advancing. Run audits after every fix — not just once.
Input
Output
Who
Time
Deployed preview URL (after Visual QA is complete)
All four audits passing with target scores
Manus AI (runs audits + fixes)
30–60 min
The Four Required Audits
Audit
Tool
Target
What It Catches
Accessibility
axe-core (WCAG 2.0 AA)
0 violations on all pages
Color contrast failures, missing alt text, form label issues, ARIA errors
Font audit
compare_fonts.py script
0 mismatches vs. reference
Missing font weights (synthesized bold), wrong letter-spacing, wrong font family
Performance
PageSpeed Insights
90+ mobile, 100 desktop
Uncompressed images, render-blocking resources, missing fetchpriority, large JS payloads
This is the most important rule in Technical QA. When fixing a color contrast failure, the fix must be applied to the specific element — not to the global CSS variable. CSS variables are used on both light and dark backgrounds. Darkening a variable to fix contrast on a cream background will break contrast on a dark background. After every contrast fix, run the contrast regression check on all pages at all viewports before declaring the fix complete.
The Font Audit Process
Run compare_fonts.py with both the reference site URL and the preview URL as arguments. The script extracts computed font-family, weight, size, letter-spacing, and text-transform from eight key element types (h1, h2, h3, nav links, body, buttons, section labels, footer) and diffs them. Any mismatch is a bug. The most common mismatch is a missing font weight file — for example, DM Sans 700 is frequently missing from the @font-face declarations, causing the browser to synthesize bold instead of using the real 700 weight file.
The Audit Loop
Run all audits. Fix all violations. Run all audits again. Repeat until all audits pass. Do not advance to Play 6 until the loop produces a clean pass on all four audits. This loop typically takes 2–3 iterations. Each iteration takes 5–10 minutes. The total time investment is worth it — sending a client a site with contrast failures or a 73 PageSpeed score undermines the value proposition.
Mobile QA Checklist
After all four automated audits pass, perform this manual mobile QA check at 390px viewport width. These items are not caught by automated tools.
Check
How to Verify
Common Failure
Sticky call bar visible
Resize to 390px — a fixed bottom bar with phone number must appear
Bar missing entirely, or overlaps page content (add body { padding-bottom: 56px; })
Touch targets ≥ 44px
Inspect all buttons and nav links — computed height must be ≥ 44px
Nav links too small; add min-height: 44px to nav link styles
No horizontal scroll
Resize to 390px and scroll horizontally — page must not overflow
Fixed-width elements or images without max-width: 100%
Font sizes ≥ 16px on inputs
Inspect all form inputs — font-size must be ≥ 16px to prevent iOS auto-zoom
Default browser input font-size is 11px; always set input { font-size: 1rem; }
Mobile nav hamburger at far right
Resize to 390px — hamburger icon must be at the far right of the nav bar
Missing margin-left: auto on hamburger button
Mobile nav panel opens correctly
Click the hamburger — full nav panel must open with logo visible
Logo invisible in nav panel (white text on white background)
Hero text readable on mobile
Resize to 390px — hero headline must be legible, not overflowing or too small
Fixed font sizes that are too large on mobile; use clamp() or media queries
Images not oversized on mobile
Check all images load correctly at 390px — no blurry or oversized images
Missing width="100%" or max-width: 100% on img elements
Play 5 complete when
axe reports 0 violations on all pages. Font audit reports 0 mismatches. PageSpeed mobile is 90+ and desktop is 100. PageSpeed SEO score is 100 on all pages (note: the .pages.dev preview domain returns x-robots-tag: noindex which drops SEO to 69 — this is expected and resolves on the production domain). All results are from the live preview URL — not from a local file:// URL. Mobile QA checklist is fully checked: sticky call bar visible, touch targets ≥ 44px, no horizontal scroll, mobile nav tested by clicking.
PLAY-BY-PLAY · PLAY 5B
Play 5B: SEO Readiness Audit
Before the site goes live, verify every on-page SEO element is correct, complete, and better than what was there before. A site that ranks worse after a rebuild is a client retention problem.
Input
Deployed preview URL + SEO baseline from Play 1B
Output
All meta titles, descriptions, schema, sitemap, and robots.txt verified and corrected
Who Runs It
Manus AI (directed by Onboarding Specialist)
Time
30–45 minutes
Pass Criteria
Zero missing titles, zero missing meta descriptions, valid schema on all pages, sitemap accessible
Critical Play: SEO regressions after a rebuild are one of the most common client complaints. This play must be completed before go-live, not after. A site that loses rankings because meta tags were missing is a refund request waiting to happen.
Step 1: Run the Automated SEO Audit
Paste the following prompt into Manus to run the full SEO audit on the deployed preview:
Please run a complete SEO readiness audit on [PREVIEW URL].
Check every page for:
1. Page title — present, unique, 50–60 characters, includes primary keyword + brand name
2. Meta description — present, unique, 150–160 characters, compelling and keyword-relevant
3. H1 tag — exactly one per page, matches page topic
4. H2/H3 structure — logical hierarchy, no skipped levels
5. Image alt text — every <img> has descriptive alt text (not empty, not "image")
6. Canonical tag — present on every page, points to correct URL
7. Open Graph tags — og:title, og:description, og:image on every page
8. JSON-LD schema — present and valid on every page (use schema.org/LocalBusiness minimum)
9. robots.txt — accessible at /robots.txt, not blocking crawlers
10. XML sitemap — accessible at /sitemap.xml, lists all pages
11. Internal links — no broken internal links
12. Mobile viewport meta tag — present on every page
Compare against the SEO baseline at /inventory/seo-baseline.md and flag any regressions.
Output a pass/fail table for each page and each check. List all failures with exact fix instructions.
Step 2: Required Schema for Every Page
Every page must have at minimum a LocalBusiness schema block. The homepage should also have WebSite schema. Service pages should have Service schema. Use the following as a template:
Both files must be accessible and correct before launch:
# robots.txt minimum content:
User-agent: *
Allow: /
Sitemap: https://[domain.com]/sitemap.xml
# sitemap.xml must:
- List every page URL
- Include <lastmod> dates
- Be accessible at /sitemap.xml
- Not include any 404 or redirect URLs
Pass Criteria
Every page has a unique title (50–60 chars) with primary keyword
Every page has a unique meta description (150–160 chars)
Every page has exactly one H1
Every image has descriptive alt text
Every page has a canonical tag
Every page has Open Graph tags
Every page has valid JSON-LD schema (validated at schema.org/validator)
A beautiful site that loads slowly loses clients and ranks lower. This play ensures every site ships with 90+ PageSpeed on mobile and desktop before it ever goes live.
Input
Deployed preview URL
Output
PageSpeed 90+ mobile, all images compressed to WebP, fonts self-hosted, lazy loading applied
Who Runs It
Manus AI (directed by Onboarding Specialist)
Time
30–60 minutes
Pass Criteria
PageSpeed Insights mobile score ≥ 90, desktop score ≥ 95
Step 1: Run PageSpeed Insights
Run PageSpeed on the homepage and the two most content-heavy pages (typically gallery and contact):
Record the scores and the top 3 opportunities listed. The most common issues are:
Issue
Fix
Impact
Images not in WebP format
Convert all images to WebP at quality 75–85
High
Images not sized correctly
Resize to max display size + 2x for retina
High
LCP image not preloaded
Add fetchpriority="high" to hero image
High
Render-blocking resources
Move CSS inline or defer non-critical CSS
Medium
Google Fonts (external)
Self-host all fonts as .woff2 files
Medium
Google Maps iframe
Add loading="lazy" to all iframes
Medium
Unused JavaScript
Remove or defer scripts not needed on load
Medium
Step 2: Image Optimization Checklist
Paste the following prompt into Manus to run automated image optimization:
Please optimize all images in the /images directory:
1. Convert all JPG/PNG files to WebP format
2. Compress each image to the smallest size that maintains visual quality (target: quality 75-85)
3. Resize any image wider than 1600px to max 1600px width
4. For hero/banner images: target file size under 150KB
5. For product/gallery images: target file size under 80KB
6. For thumbnails/icons: target file size under 30KB
7. Add width and height attributes to all <img> tags to prevent layout shift
8. Add loading="lazy" to all images except the first visible image on each page
9. Add fetchpriority="high" to the LCP (largest/first visible) image on each page
Report: original size vs. new size for each image, and total savings.
Step 3: Font Self-Hosting
External font services (Google Fonts, Adobe Fonts) add a render-blocking network request. All fonts must be self-hosted:
# Download fonts from Google Fonts as woff2:
# 1. Go to fonts.google.com
# 2. Select the font family and all required weights
# 3. Use google-webfonts-helper.herokuapp.com to download woff2 files
# 4. Place in /fonts/ directory
# 5. Add @font-face declarations in CSS:
@font-face {
font-family: 'Font Name';
font-style: normal;
font-weight: 400;
font-display: swap;
src: url('../fonts/font-name-400.woff2') format('woff2');
}
# IMPORTANT: Download ALL weights used in the design.
# Missing a weight causes the browser to synthesize it (looks wrong).
Pass Criteria
PageSpeed Insights mobile score ≥ 90
PageSpeed Insights desktop score ≥ 95
All images converted to WebP
Hero/LCP image has fetchpriority="high"
All non-hero images have loading="lazy"
All fonts self-hosted (no Google Fonts CDN requests)
Verify the site scores 99/100 or higher on the aifriendliness.com scanner before advancing to Content QA. This is a non-negotiable gate.
Input
Output
Who
Time
Deployed preview URL (after Performance Optimization is complete)
99/100 or 100/100 AI Friendliness score
Manus AI (runs audit + fixes)
15–30 min
The Real Scoring System (13 Categories, 108 Points)
The aifriendliness.com scanner uses a 13-category scoring system totalling 108 points, normalized to a 0–100 percentage. The old 4-category description in this playbook was inaccurate. The table below shows every category, its weight, the exact scoring formula, and how to achieve the maximum score by default in every build.
Include a visible FAQ section AND a <script type="application/ld+json"> FAQPage schema block in the <head>
Clear Definitions
5
2+ definition patterns = 5/5. Pattern: <strong>Term</strong> – definition text (literal en dash –, not –)
Add a “Glossary: Key Terms Explained” <details> accordion item as the last item inside the FAQ section with 4+ entries. Do not create a standalone Key Terms section — it looks orphaned and breaks visual flow.
Citation Presence
10
raw 0→0, 1→3, 2→6, 3→8, ≥4→10. Need 4+ external links.
Include links to: BBB profile, Yelp/Google profile, industry resource (e.g., portland cement association), and 1 more credible external source
Statistics Presence
15
raw 0→0, 1→3, 2→6, 3→8, ≥4→10 (then ×1.5). Need 4+ stat matches.
Include 5+ statistics in paragraph text: percentages (e.g., “98% satisfaction”), years in business, number of projects, ratings (e.g., “4.9 out of 5 stars”), and phrases like “on average”. Do not drop industry stats into the Our Story or What We Do sections — this clutters brand-voice copy with data that feels out of place. Instead, add a dedicated FAQ accordion entry titled “Why choose [service]? Industry facts.” and place all third-party statistics (BLS, NAHB, Census Bureau, etc.) there. This keeps the AI scanner satisfied while keeping the main sections clean and human.
Add a “Quick Facts” section with 250+ short sentences (4–6 words, monosyllabic words). Include “What We Do”, “How We Work”, and “Towns We Serve” columns. This is the only reliable way to push Flesch above 70 for trade/contractor sites.
99/100 is the confirmed ceiling for trade/contractor sites
The Readability category scores 9/9 only at Flesch 81+. Trade and contractor sites use core service keywords (masonry, tuckpointing, construction, driveways, residential, commercial) that carry 3+ syllables and are non-negotiable for SEO and professional credibility. These words cannot and should not be replaced. The “Quick Facts” section technique gets Readability to 8/9 (Flesch ~71), yielding 99/100. This is the correct target for all trade sites. The 1-point gap is a known, intentional tradeoff — not a failure.
Safe word substitutions (apply to every build): “estimate” → “quote”, “typically” → “often”, “properly” → “right”, “completed” → “done”, “every” → “each”, “efflorescence” → “white salt stains”, “multigenerational” → “family-run”. These save ~70 syllables and push Flesch from ~67 to ~71, safely above the 8/9 threshold, without touching any service keywords.
How to Run the Audit
Use the scan.aifriendliness.com web scanner or call the API directly. The API endpoint is POST https://scan.aifriendliness.com/api/analyze-batch/ with body {"urls": ["https://your-site.com"]}. The Agency Unlimited subscription credentials are stored in the Tokens page of this playbook.
API scan command
python3 -c "
import requests, json
r = requests.post(
'https://scan.aifriendliness.com/api/analyze-batch/',
headers={'Content-Type': 'application/json', 'Authorization': 'Bearer pk_a080a2c7461985084e71c34e44508'},
json={'urls': ['https://your-site.pages.dev']}
)
d = r.json()['results'][0]['data']
print(d['overallPercentage'], '%')
for k, v in d['results'].items():
print(f' {k}: {v["percentage"]}%')
"
The Quick Facts Section: Human-Friendly + Machine-Friendly
Every site must include a “Quick Facts” section (dark background, placed before the CTA). This section serves two purposes simultaneously: it achieves Readability 8/9 by injecting hundreds of short monosyllabic sentences, and it presents a visually engaging summary of the business to human visitors. The key insight is that the machine-readable text is hidden with sr-only (screen-reader-only CSS), while the visible section uses stat cards, icon bullet lists, numbered steps, and tag pills.
Critical: Sites must be BOTH machine-friendly AND human-friendly
The goal is not to game audits — it is to build perfect websites that convert visitors. A wall of tiny monosyllabic text is not acceptable for human visitors. The sr-only technique solves this: the machine-readable sentences are hidden from visual display but still present in the HTML for the AI Friendliness scorer. The visible section uses professional design patterns that build trust and drive conversions.
Quick Facts section HTML template (human-friendly version)
<!-- CSS required in <style> block -->
.sr-only { position:absolute; width:1px; height:1px; padding:0; margin:-1px; overflow:hidden; clip:rect(0,0,0,0); white-space:nowrap; border:0; }
<section class="section section-dark" aria-labelledby="facts-heading">
<div class="container">
<div class="section-heading center">
<span class="section-label">At a Glance</span>
<h2 id="facts-heading">Why Clients Choose Us</h2>
</div>
<!-- VISIBLE: Stat cards (human-friendly) -->
<div style="display:grid; grid-template-columns:repeat(auto-fit,minmax(160px,1fr)); gap:20px; max-width:900px; margin:0 auto 48px; text-align:center;">
<div style="background:rgba(255,255,255,0.07); border:1px solid rgba(255,255,255,0.12); border-radius:10px; padding:28px 16px;">
<div style="font-size:2.4rem; font-weight:800; color:#fff;">[X]+</div>
<div style="font-size:0.8rem; font-weight:600; text-transform:uppercase; letter-spacing:0.08em; color:rgba(255,255,255,0.65); margin-top:8px;">Years in Business</div>
</div>
<!-- Repeat for: Projects Completed, Star Rating, Repeat Clients %, BBB Rating -->
</div>
<!-- VISIBLE: Two-column cards (human-friendly) -->
<div style="display:grid; grid-template-columns:repeat(auto-fit,minmax(280px,1fr)); gap:32px; max-width:900px; margin:0 auto 48px;">
<div style="background:rgba(255,255,255,0.05); border:1px solid rgba(255,255,255,0.1); border-radius:10px; padding:32px;">
<h3 style="color:#fff; margin:0 0 20px;">What We Do</h3>
<ul style="list-style:none; padding:0; margin:0; display:flex; flex-direction:column; gap:10px;">
<li style="display:flex; align-items:center; gap:10px; font-size:0.92rem; color:rgba(255,255,255,0.85);"><span style="color:#c8232c; font-weight:700;">✓</span> [Service 1]</li>
<!-- Repeat for each service -->
</ul>
</div>
<div style="background:rgba(255,255,255,0.05); border:1px solid rgba(255,255,255,0.1); border-radius:10px; padding:32px;">
<h3 style="color:#fff; margin:0 0 20px;">How We Work</h3>
<div style="display:flex; flex-direction:column; gap:16px;">
<div style="display:flex; gap:14px; align-items:flex-start;">
<span style="display:inline-flex; width:28px; height:28px; background:#c8232c; border-radius:50%; align-items:center; justify-content:center; flex-shrink:0; font-size:0.75rem; font-weight:800; color:#fff;">1</span>
<div>
<div style="font-size:0.92rem; font-weight:700; color:#fff;">Free Quote</div>
<div style="font-size:0.85rem; color:rgba(255,255,255,0.65);">No cost, no pressure.</div>
</div>
</div>
<!-- Repeat for steps 2 and 3 -->
</div>
</div>
</div>
<!-- VISIBLE: Towns tag cloud (human-friendly) -->
<div style="max-width:900px; margin:0 auto; text-align:center;">
<h3 style="font-size:0.85rem; font-weight:700; text-transform:uppercase; letter-spacing:0.1em; color:rgba(255,255,255,0.5); margin-bottom:16px;">Towns We Serve</h3>
<div style="display:flex; flex-wrap:wrap; gap:8px; justify-content:center;">
<span style="background:rgba(255,255,255,0.08); border:1px solid rgba(255,255,255,0.15); border-radius:20px; padding:5px 14px; font-size:0.82rem; color:rgba(255,255,255,0.8);">[Town 1]</span>
<!-- Repeat for each town -->
</div>
</div>
<!-- HIDDEN: Machine-readable text for AI Friendliness scorer -->
<div class="sr-only" aria-hidden="true">
<p>[Track record paragraph: short sentences with stats. e.g. "We have been at this for [X] years. We have done [N]+ jobs. About [N]% of our work comes from past clients. Our score is [X] out of 5 stars."]</p>
<p>[Services paragraph: 20 short sentences. e.g. "We lay tile and stone. We fix old floors. We set grout."]</p>
<p>[Process paragraph: 50+ monosyllabic sentences. e.g. "We give free quotes. We show up on time. We do the job right. We clean up when done. We stand by our work."]</p>
<p>[Towns paragraph: 50 sentences. e.g. "We work in [Town 1]. We work in [Town 2]. We work in [Town 3]."]</p>
</div>
</div>
</section>
Glossary Accordion Item (inside FAQ section)
Every site must include a “Glossary: Key Terms Explained” accordion item as the last <details> item inside the FAQ section — not as a standalone section. This keeps definitions contextually grouped with the FAQ, avoids orphaned content blocks, and satisfies the AI Friendliness “Clear Definitions” detector. Use 4+ industry terms with the exact <strong>Term</strong> – definition format. The en dash must be a literal – character (Unicode U+2013), not the HTML entity –.
Glossary accordion item — add as the LAST <details> inside the FAQ <section> (use literal en dash – character)
<!-- Add this as the LAST item inside the existing FAQ accordion section -->
<details class="faq-item">
<summary class="faq-question">Glossary: Key Terms Explained</summary>
<div class="faq-answer">
<dl>
<dt>[Term 1]</dt>
<dd><strong>[Term 1]</strong> – [definition sentence]</dd>
<dt>[Term 2]</dt>
<dd><strong>[Term 2]</strong> – [definition sentence]</dd>
<dt>[Term 3]</dt>
<dd><strong>[Term 3]</strong> – [definition sentence]</dd>
<dt>[Term 4]</dt>
<dd><strong>[Term 4]</strong> – [definition sentence]</dd>
</dl>
</div>
</details>
<!-- CRITICAL: dt = term name only. dd = <strong>Term</strong> – definition (literal U+2013 en dash).
The scanner reads the <dd> text for the <strong>Term</strong> – pattern.
dt must have a matching dd or W3C validation will fail. -->
FAQPage JSON-LD Template
The FAQ Structure category requires both a visible FAQ section AND a FAQPage JSON-LD schema block. The microdata approach (itemscope itemtype="https://schema.org/FAQPage") does not satisfy the scanner. Use JSON-LD only.
Every build prompt must instruct Manus to include all of the following. If any item is missing, the score will be below 99/100 and the play fails.
robots.txt with User-agent: *, Allow: /, and Sitemap: directive
sitemap.xml with all page URLs
llms.txt with business name, services, contact info, and page links
LocalBusiness JSON-LD schema in <head>
FAQPage JSON-LD schema in <head> (not microdata)
Visible FAQ section with 5+ questions and short answers (<25 words each)
Glossary accordion item as the last <details> item inside the FAQ section — 4+ definitions using <strong>Term</strong> – definition format (literal – character). Do not create a standalone Key Terms section.
Quick Facts section with 4 columns: Track Record (with stats), What We Do, How We Work (50+ monosyllabic sentences), Towns We Serve (50+ "We work in [Town]." sentences)
5+ statistics in paragraph text: percentages, years in business, project count, star rating, repeat client rate
The aifriendliness.com scanner returns 99/100 or 100/100 for the deployed preview URL. Run via the web scanner at scan.aifriendliness.com or via the API command above. All 13 categories must be at or near maximum. The local PHP scorer at /home/ubuntu/aifriendliness-test/test_score.php can be used for unlimited offline verification.
Verify every piece of factual content against the client brief. One wrong phone number or incorrect business hour can cost the client a customer.
Input
Output
Who
Time
Deployed preview URL + completed client brief
All factual content verified accurate
Onboarding Specialist
20–30 min
Content Writing Rules
Before verifying factual accuracy, check that all customer-facing copy follows these two non-negotiable writing rules. They apply to every paragraph, heading, and sentence a visitor reads. They do not apply to code, CSS class names, decorative design elements (such as a short horizontal rule next to a section label), or technical HTML attributes.
Rule 1: No em dashes or en dashes in customer-facing prose
Em dashes (—) and en dashes used as sentence connectors are one of the clearest signals that copy was written by AI. Visitors notice this even if they cannot name it. Never use — or – as a sentence connector in any customer-facing paragraph, heading, or list item. Rewrite the sentence instead. Example: “We do great work — call us today” becomes “We do great work. Call us today.” The only acceptable use of a dash in customer-facing content is a decorative design element (such as a short horizontal rule next to a section label) that is clearly not part of a sentence.
Rule 2: Industry stats and third-party data belong in the FAQ accordion, not in brand-voice sections
Statistics from the BLS, NAHB, Census Bureau, or other third-party sources are valuable for AI Friendliness scoring but feel out of place inside the Our Story, About, or What We Do sections. Dropping stat-dense paragraphs into brand-voice copy makes those sections feel like a Wikipedia article rather than a contractor’s website. Place all third-party industry statistics inside a dedicated FAQ accordion entry titled “Why choose [service]? Industry facts.” This keeps the AI scanner satisfied while keeping the main sections clean and authentic. The FAQ accordion is the correct home for this content because visitors expect informational content there and the scanner reads it as body text.
What to Verify
Open the client brief and the preview site side by side. Go through every factual claim on the site and verify it against the brief. This is not a proofreading exercise — it is a factual accuracy check. The items most likely to be wrong are the ones Manus had to infer or generate from incomplete information.
Footer, contact page, Google Maps embed, JSON-LD schema
Wrong suite number, wrong zip code
Business hours
Contact page hours table, footer, JSON-LD schema
Wrong closing time, missing Saturday/Sunday
Service list
Homepage services section, services page, nav dropdown
Missing service, wrong service name
Service area
Homepage, about page, footer, meta description
Missing city, wrong county name
Year established
About page, stats bar, footer
Off by one year
Google review count and rating
Reviews page, stats bar, homepage
Outdated count, wrong rating
Social media links
Footer, contact page
Wrong URL, link goes to wrong profile
License/certification numbers
Footer, about page
Wrong number, expired certification listed
Submitting Content Corrections
List all corrections in a single message to Manus: "Please make the following content corrections: 1. Phone number should be (425) 654-4144, not (425) 654-4114. 2. Hours on Saturday should be 9am–3pm, not 9am–5pm." After Manus deploys the corrections, spot-check each corrected item on the live preview URL before advancing.
Play 6 complete when
Every factual item in the table above has been verified against the client brief. All corrections have been applied and confirmed live. No content item says "TBD," "placeholder," or contains a generic value that should be client-specific.
Play-by-Play · Play 7
Play 7: Deploy to Preview
Push the final QA-passing site to a shareable preview URL for client review. This is the URL you send to the client.
Input
Output
Who
Time
QA-passing site files
Live preview URL (e.g., clientname.ddwebsitepreview.com)
Onboarding Specialist
15 min
The Preview URL Convention
All preview sites use the ddwebsitepreview.com domain with a client-specific subdomain: clientname.ddwebsitepreview.com. This domain is configured in Cloudflare Pages. The preview URL is what the client sees during the review phase — it is not the final client domain. Using a consistent preview domain makes it easy to manage multiple client sites simultaneously and prevents confusion between preview and production.
Deploy Steps
If Manus has already deployed to the preview URL during the build phase, this play may already be complete. Verify by navigating to the preview URL and confirming the latest QA-passing version is live. If the URL is not live or is showing an older version, ask Manus to redeploy using Wrangler (see the exact command below).
After deployment, verify the preview URL is accessible from outside the Manus sandbox by opening it in a regular browser window (not the Manus browser tool). Confirm all pages load, all images display, and the mobile nav works correctly.
The Cloudflare Pages Branch Rule — Read This Every Time
The single most common deployment failure is a mismatch between the branch Manus commits to and the branch Cloudflare Pages is watching. This causes the production URL to silently serve an old version while a branch-preview URL serves the correct one. The client sees the old version. You see the new version in the branch preview. Nobody notices until the client reports missing features.
Deployment Verification Checklist (mandatory — run every deploy)
Step 1 — Confirm the production branch. Before deploying, check which branch Cloudflare Pages treats as production: curl -s "https://api.cloudflare.com/client/v4/accounts/ACCOUNT_ID/pages/projects/PROJECT_NAME" -H "Authorization: Bearer TOKEN" | python3 -c "import sys,json; r=json.load(sys.stdin)['result']; print('Production branch:', r['production_branch'])". The result must match the branch you are committing to. If it says master but you are on main, either switch branches or update the production branch setting before deploying.
Step 2 — Always deploy with wrangler, not git push alone. Git push only triggers a Cloudflare Pages build if the GitHub integration is active and the pushed branch matches the production branch. Wrangler direct upload bypasses this entirely and always deploys to the correct project. The correct command is: CLOUDFLARE_API_TOKEN=TOKEN CLOUDFLARE_ACCOUNT_ID=ACCOUNT_ID CI=true npx wrangler@3 pages deploy /path/to/site --project-name=PROJECT_NAME --branch=main. Note: CLOUDFLARE_ACCOUNT_ID must be set as an environment variable — the --account-id flag does not exist in wrangler v3.
Step 3 — Verify the production URL, not the branch preview URL. Cloudflare Pages creates two types of URLs: (a) the production alias (projectname.pages.dev or your custom domain) and (b) branch-specific preview URLs (HASH.projectname.pages.dev or main.projectname.pages.dev). After every deploy, check the production alias specifically — not the branch preview. Run: curl -sL "https://projectname.pages.dev/" | wc -c and compare the byte count against your local file: wc -c index.html. They must match. A mismatch means the production alias is still serving an old deployment.
Step 4 — If the production URL returns HTTP 500. A 500 from Cloudflare Pages after a direct upload means the deployment was accepted but the CDN cannot serve it. This usually happens when the direct upload API is used with large files (images, fonts) via Python requests — the connection aborts mid-upload and Cloudflare stores a corrupt deployment. The fix is to always use wrangler CLI for deployments with images and fonts. Wrangler handles chunked uploads correctly. Never use the raw POST /deployments API with binary files larger than ~100KB total.
Step 5 — If you need to change the production branch. Use the PATCH API: curl -s -X PATCH "https://api.cloudflare.com/client/v4/accounts/ACCOUNT_ID/pages/projects/PROJECT_NAME" -H "Authorization: Bearer TOKEN" -H "Content-Type: application/json" -d '{"production_branch": "main"}'. After changing the branch, you must also redeploy — changing the branch setting alone does not update the live site.
Play 7 complete when
The production alias URL (not just a branch preview URL) is live and accessible from a regular browser. The byte count of the production URL matches the local file: curl -sL "https://projectname.pages.dev/" | wc -c equals wc -c index.html. All pages load without errors. The site reflects the latest QA-passing version. The URL is ready to share with the client.
Play-by-Play · Play 8
Play 8: Client Review
Send the preview URL to the client with clear instructions for how to review and how to submit feedback. Set expectations for the revision process.
Input
Output
Who
Time
Live preview URL
Client approval or consolidated revision list
Onboarding Specialist (sends) + Client (reviews)
24–48 hours for client response
The Review Email
Send the client a short, structured email. Do not write a long email — clients will not read it. The email should contain: the preview URL as a large, obvious link; three specific things to look for (accuracy of business information, completeness of services list, overall visual impression); a clear deadline for feedback (48 hours is standard); and a single sentence explaining the revision process ("We include one round of revisions — please consolidate all feedback into a single list").
Managing Revision Scope
The standard plan includes one round of revisions. A revision round is a single consolidated list of changes — not an ongoing back-and-forth. When the client sends feedback, acknowledge it and confirm which items are in scope. Changes to factual content (wrong phone number, wrong hours) are always in scope. Changes to visual design that were not discussed during the kickoff call are out of scope for the revision round and should be quoted as additional work.
Play 8 complete when
The client has responded with either explicit approval ("Looks great, ready to go live") or a consolidated revision list. A non-response after 48 hours is not approval — follow up by phone.
Play-by-Play · Play 9
Play 9: Revisions
Apply the client's revision list in a single pass. Re-run QA after every revision deployment — client changes can introduce new technical issues.
Input
Output
Who
Time
Client revision list
Updated site with all revisions applied, QA re-passed
Manus AI (directed)
30–60 min
Submitting Revisions to Manus
Paste the client's revision list into Manus as a numbered list. Be specific: "1. Change the phone number in the header from (425) 654-4114 to (425) 654-4144. 2. Add 'Heated Floors' to the services list on the homepage. 3. Replace the hero image with the photo of the marble bathroom I'm uploading now." Upload any new assets before submitting the revision message.
Re-Running QA After Revisions
After Manus applies revisions and redeploys, re-run the axe accessibility audit and the contrast regression check. Client-requested changes — especially color changes, image replacements, and copy additions — can introduce new violations. This step takes 5 minutes and prevents sending the client a revised site with new technical issues.
Play 9 complete when
All revision items are applied and confirmed live on the preview URL. axe reports 0 violations after the revision deployment. The client has confirmed the revisions are correct (or the revision round is complete per the contract terms).
Play-by-Play · Play 10
Play 10: Go Live
Connect the client's domain to the site and confirm the live URL is working with HTTPS. This is the only play that requires access to the client's domain registrar.
Input
Output
Who
Time
Client approval + domain registrar access
Site live on client domain with HTTPS
Onboarding Specialist
30–45 min
Before Touching DNS
Confirm the following before making any DNS changes: the client has given explicit approval to go live; the site passes all four audits on the preview URL; you have login access to the client's domain registrar; and the client's existing site (if any) has been backed up or the client has confirmed they do not need the old site preserved.
DNS Configuration Steps
The specific steps depend on whether the client's domain is registered with Cloudflare Registrar or a third-party registrar. For Cloudflare Registrar (preferred): add the custom domain in Cloudflare Pages settings, then add a CNAME record pointing to the Pages URL. SSL is issued automatically within minutes. For third-party registrars: add the custom domain in Cloudflare Pages settings, then update the nameservers at the registrar to point to Cloudflare's nameservers. DNS propagation can take up to 24 hours — warn the client.
Post-Launch Verification
After DNS propagates, verify: the site loads at https://clientdomain.com (with HTTPS, not HTTP); the padlock icon is visible in the browser; all pages load without errors; the contact form submits successfully (test with a real submission); the phone number is a tap-to-call link on mobile; and the Google Maps embed shows the correct location.
Play 10 complete when
The site is live at the client's domain with HTTPS. All pages load. The contact form works. The phone number is a tap-to-call link. The padlock is visible. UptimeRobot monitoring has been set up (see Play 11).
PLAY-BY-PLAY · PLAY 10B
Play 10B: Post-Launch Monitoring Setup
The site is live. Now make sure you’ll know immediately if anything breaks, and that Google knows the new site exists.
Input
Live site URL (on client’s custom domain)
Output
Google Search Console verified, Google Analytics active, uptime monitor configured
Who Runs It
Onboarding Specialist
Time
20–30 minutes
Pass Criteria
GSC shows site as verified; GA4 shows live data; uptime alert configured
Log in to UptimeRobot and create a new HTTP(s) monitor for the client's domain. Set the check interval to 5 minutes. Add the Quarterback's email address as an alert contact. Name the monitor "[Client Name] — [Domain]". This takes 3 minutes and ensures the Quarterback is notified immediately if the site goes down.
The Quarterback Briefing
Send the Quarterback a brief internal handoff note containing: the client's name and contact information, the live URL and preview URL, the GitHub repository name, the Cloudflare Pages project name, a summary of any ongoing issues or client preferences noted during the build, and the client's plan level (which determines what maintenance is included). The Quarterback should be able to handle any client request without contacting the Onboarding Specialist.
The Go-Live Email to the Client
Send the client a go-live email from the Quarterback's email address (not the Onboarding Specialist's). This establishes the Quarterback as the primary point of contact going forward. The email should contain: congratulations on the launch, the live URL, the Quarterback's name and contact information, a brief explanation of what to do if they need changes ("Just email me and I'll handle it"), and a request for a Google review.
Play 11 complete when
UptimeRobot is monitoring the live URL. The Quarterback has received the handoff briefing and confirmed they have everything they need. The go-live email has been sent to the client from the Quarterback's address.
PLAY-BY-PLAY · PLAY 11B
Play 11B: Google Business Profile Sync
The website is live, but Google’s local search results still point to the old site. Update the Google Business Profile immediately after launch to keep NAP (Name, Address, Phone) consistent and protect local rankings.
Input
Live site URL on client’s custom domain
Output
GBP website field updated, NAP consistent across GBP and website, photos refreshed if needed
Who Runs It
Onboarding Specialist
Time
15–20 minutes
Pass Criteria
GBP website URL matches live site URL; phone, address, and hours match website exactly
Why This Play Exists
NAP consistency (Name, Address, Phone) is a local SEO ranking factor. If the GBP says one phone number and the website says another, Google treats this as a trust signal problem. After every rebuild, the GBP must be audited and updated to match the new site exactly.
Update to the new live URL: https://[clientdomain.com]
Save and confirm the change appears in the Knowledge Panel within 24 hours
Step 2: NAP Consistency Audit
Compare the GBP data against the website. Every field must match exactly (same formatting, same phone number format, same address abbreviations):
Field
GBP Value
Website Value
Match?
Business name
Check GBP
Check footer/contact page
Must match
Phone number
Check GBP
Check header/contact page
Must match
Street address
Check GBP
Check contact page
Must match
City, State, ZIP
Check GBP
Check contact page
Must match
Business hours
Check GBP
Check contact page
Must match
Website URL
Check GBP
New live URL
Must match
Step 3: Photo Refresh (Optional but Recommended)
If the rebuild included new photography or updated brand assets, add them to the GBP profile:
Add the new logo (square format, minimum 250×250px)
Add a cover photo from the new site’s hero section
Add any new project photos from the gallery
Remove any outdated photos that no longer reflect the business
Step 4: Request a New Review (Optional)
A site launch is a great moment to ask satisfied clients for a Google review. The GBP review link can be found in the GBP dashboard under “Get more reviews”. Send this link to 2–3 recent clients with a personal note.
Pass Criteria
GBP website URL updated to new live domain
Business name matches exactly between GBP and website
Phone number matches exactly between GBP and website
Address matches exactly between GBP and website
Business hours match exactly between GBP and website
Handle client change requests efficiently using Manus. Every change goes through the same three-step process: understand the request, direct Manus, verify the result.
Input
Output
Who
Time
Client change request (email or call)
Updated live site, client confirmed
Client Success Quarterback
15–30 min per request
The Maintenance Request Process
When a client submits a change request, follow this three-step process every time. First, confirm you understand the request by repeating it back to the client in writing: "Just to confirm — you'd like us to update your business hours to show Saturday 9am–2pm instead of 9am–5pm. Is that correct?" This prevents doing the wrong thing. Second, open the client's Manus task (or start a new one), provide the GitHub repository name and Cloudflare Pages project name, and describe the change clearly. Third, after Manus deploys the change, verify it on the live site and send the client a one-sentence confirmation: "Done — your updated hours are now live at [URL]."
Directing Manus for Maintenance Tasks
When starting a maintenance task in Manus, always provide the following context at the start of the message: the client's live URL, the GitHub repository name, the Cloudflare Pages project name, and the specific change requested. Without this context, Manus will spend time trying to find the project files. With this context, Manus can go directly to the relevant file and make the change.
Request Type
Typical Manus Instruction
Time
Update business hours
"Update the hours on the contact page and in the JSON-LD schema to show [new hours]. Repo: [name]. Project: [name]."
10 min
Add a new service
"Add '[Service Name]' to the services list on the homepage and the services page. Repo: [name]. Project: [name]."
15 min
Replace a photo
"Replace the [location] photo with the attached image. Compress to WebP. Repo: [name]. Project: [name]." (attach new photo)
15 min
Update phone number
"Update the phone number everywhere on the site from [old] to [new]. Check header, footer, contact page, JSON-LD schema, and tap-to-call links. Repo: [name]. Project: [name]."
15 min
Add a new page
"Add a new page called '[Page Name]' with the following content: [content]. Match the visual style of the existing pages. Repo: [name]. Project: [name]."
30–45 min
After Every Maintenance Change
After every maintenance deployment, run a quick spot-check: navigate to the affected page on the live site, confirm the change is correct, and confirm no other content was accidentally changed. For changes that touch CSS or colors, run the axe contrast check on the affected page. For changes that add new pages, run the full axe audit on the new page. Do not skip the spot-check — Manus occasionally makes changes to adjacent elements when editing a specific element.
Play 12 complete when
The change is live on the client's domain. The client has been notified. The spot-check confirms the change is correct and no regressions were introduced. The request is documented in the client's maintenance log.
Operations
Tokens
All API tokens and credentials used across the Dotcom Design workflow. Update this page whenever tokens are rolled. Always refer here before starting a task that requires API access.
Security Notice
These tokens grant access to live systems. Do not share this page publicly. When a token is compromised or rolled, update this page immediately so the team always has the current credentials.
Manus Agent Token
Used to share tasks and collaborate with the Manus AI agent. Provide this token at the start of any Manus session when prompted.
Field
Value
Token
GVeoPzBYxrIp88l8bpVi6UdgdSd55aizl5IJ0SM2
Where to find it
Manus app → your profile → Share / Collaborate → copy the agent token
When to roll it
If you suspect it has been exposed; Manus generates a new one automatically when you click Roll
Last updated
March 2026
Cloudflare Workers / Pages API Token
Used to interact with the Cloudflare API — checking deployment status, triggering redeployments, and managing Workers and Pages projects.
Field
Value
Token
FUI7Fnf0XxRk3kXgZ0cRvqZiDvX0kbMWz7aR8esB
Where to find it
Cloudflare Dashboard → My Profile (top-right avatar) → API Tokens → Edit token or Create Token
If exposed or compromised; go to API Tokens and click Roll on the token
Last updated
March 2026
GitHub Personal Access Token
Used by the Manus agent and local CLI to push code to GitHub repositories under the dotcomdesigniowa organization. Required for all site builds and deployments.
Field
Value
Token
ghu_rrRKV8tzwJhdh8mfl6RUEuqW9bKamn3ob8Qu
Where to find it
GitHub → Settings → Developer settings → Personal access tokens → Tokens (classic) or Fine-grained tokens
Required scopes
repo (full), workflow, read:org
When to roll it
If exposed or expired; generate a new token and update the Manus agent environment and this page
Last updated
March 2026
Google PageSpeed Insights API Key
Used to run PageSpeed Insights audits programmatically without hitting the unauthenticated quota limit. Pass as the key query parameter in PSI API calls.
Field
Value
API Key
AIzaSyAhetwikuDs7FhWrrpv4ZTuaciZsCw4Gik
Where to find it
Google Cloud Console → APIs & Services → Credentials
If exposed or compromised; create a new key in Google Cloud Console and update here
Last updated
March 2026
AI Friendliness API Credentials
Used to run unlimited AI Friendliness scans via the scan.aifriendliness.com API. The Agency Unlimited plan removes the 10-scan/day free limit. Manus calls the internal API endpoint directly (POST https://scan.aifriendliness.com/api/analyze-batch/) using these credentials.
Field
Value
Plan
Agency Unlimited
User ID
10173872
Public Key
pk_a080a2c7461985084e71c34e44508
Secret Key
sk_4gw%%QwE6M?Dc+:@Lq9y_W{J4e->r
WordPress License Key
sk_5jvmWzuoDVU!b@Uo54!i9VE5p8@#O
Where to find it
aifriendliness.com → Login → Account → ID & Keys
API endpoint
POST https://scan.aifriendliness.com/api/analyze-batch/ with body {"urls":["https://site.com"]}
When to roll it
If exposed; log in to aifriendliness.com and regenerate from the ID & Keys page
Last updated
March 2026
How to Provide Tokens to Manus
At the start of a new Manus task that requires API access, paste the relevant tokens into the chat in this format:
Manus will use these tokens for the duration of the session. You do not need to provide all three every time — only the ones relevant to the task at hand.
Token hygiene
Roll all three tokens on a quarterly basis as a security best practice, even if no exposure has occurred. Update this page immediately after rolling.
Operations
Multi-Agent Workflow
How to run multiple Manus agents across multiple tasks while keeping every build aligned to this Playbook as the single source of truth.
The Core Problem
Each Manus task runs in an isolated sandbox. A new task has no memory of previous tasks, no knowledge of decisions made in other tasks, and no awareness of standards you have established over time. Without a deliberate system, each agent will make its own decisions about how to build, name, and deploy things — and the results will diverge quickly across clients and agents.
The solution is to make the Playbook the first thing every agent reads at the start of every task. This is not optional. It is the mechanism that ensures consistency regardless of how many agents are running simultaneously.
How to Start Every Task Correctly
At the beginning of any new Manus task, your first message should include three things: the Manus Agent token, the Cloudflare API token, and a reference to the Playbook. The exact format is:
What to Include
Why
Manus Agent token
Connects the task to your account and enables collaboration
Cloudflare API token
Allows the agent to deploy directly without waiting for you to log in
"Refer to the DD Playbook"
Triggers the Playbook skill, which tells the agent to read this document before planning anything
Example opening message: “Manus Agent: [token] — Cloudflare: [token] — Refer to the DD Playbook. Build the website for [Client Name] using the reference site at [URL].”
The Playbook is not a reference document you consult occasionally. It is the operating system for every build. When you encounter a situation where the process feels inefficient, unclear, or broken — the right response is not to improvise. The right response is to finish the task, then come back and update the Playbook so the next agent handles it correctly.
Think of it this way: every lesson learned on a client build is only valuable if it gets written into the Playbook. An insight that stays in your head or in a task thread dies when that task ends. An insight written into the Playbook survives and improves every future build.
Running Multiple Agents Simultaneously
You can run multiple Manus tasks at the same time — one per client, or one per phase of a single client build. Each task is isolated, but they all share the same Playbook. The practical rules are:
Rule
Reason
One task per client at a time
Prevents two agents from pushing conflicting changes to the same GitHub repo or Cloudflare project
Each task starts with the Playbook reference
Ensures every agent is working from the same standards, not inventing its own
All tokens come from the Tokens page
Single source of truth; when you roll a token, you update one place and all future tasks get the new value
Playbook updates happen in their own task
Keeps build tasks focused; Playbook maintenance is a separate, deliberate act
Updating the Playbook After a Build
After every client build, spend five minutes asking: what did this build teach us that is not yet in the Playbook? Common candidates include new failure modes discovered during QA, shortcuts that saved time, steps that were unclear and caused confusion, and new tools or CSS patterns that should become standard. Open a new Manus task, reference the Playbook, and say: “Update the Playbook with the following lessons from the [Client] build: [list].” The agent will find the right pages and add the content.
The Playbook compounds over time
The first build takes the most effort. The second build is faster because the first build's lessons are in the Playbook. By the fifth build, the agent is reading a document that contains the accumulated knowledge of four complete builds. This is the compounding return on maintaining the Playbook consistently.