The kickoff call is the foundation of every build. Everything that follows — the brief, the build, the SEO strategy — depends on the quality of information gathered here. The call should run 45 minutes. Do not rush it. A thorough kickoff prevents revision loops later.

Before the Call

Look up the client's existing website (if they have one) and spend 10 minutes reviewing it. Note the services they list, the cities they mention, and any obvious gaps or outdated content. This preparation allows you to ask better questions and catch inconsistencies during the call.

Call Structure (45 Minutes)

Design Sliders

Ask the client to score each slider from 1 to 10. These scores directly inform the build prompt in Step 5. Record all six scores.

Client Brief Fields

Every field in the client brief must be filled before leaving this step. Do not leave any field blank. If the client does not know the answer, note "TBD — follow up" and schedule a follow-up before Step 5.

If the client has an existing website, use Manus to extract all usable content before it is replaced. This step ensures no copy, imagery, or data is lost during the transition. Even a poorly designed old site often contains accurate business information that would take hours to re-gather.

Manus Scrape Prompt

Open a Manus task and submit the following prompt, replacing the URL with the client's actual site:

Please scrape the following website and extract all content for a rebuild:
[CLIENT WEBSITE URL]

Extract and organize the following:
1. All page copy (home, about, services, contact, and any other pages)
2. All images — download and save as WebP where possible
3. Logo files — save as PNG and SVG if available
4. Business information: name, phone, address, hours, service area
5. All existing services and service descriptions
6. Any testimonials or reviews displayed on the site
7. Team member names and bios
8. Any license numbers, certifications, or trust badges
9. Existing page structure (list all pages found)
10. Any existing integrations (contact forms, chat widgets, booking tools)

Organize everything into a folder called /assets/ and provide a summary
of what was found and what was missing or inaccessible.

What to Do With the Output

Review the Manus output carefully. Cross-reference the extracted business information against the client brief from Step 1. Any discrepancies — different phone numbers, different service lists, different addresses — must be resolved with the client before Step 5. Do not assume the website is correct; the client brief takes precedence.

If the Client Has No Existing Website

If this is a brand-new website with no existing site to scrape, skip the Manus scrape. Instead, use the client brief from Step 1 as the sole content source. Note in the brief that no existing site was available. Proceed directly to Step 3.

Site Inventory Checklist

Before any build work begins, you need access to the client's domain registrar. DNS changes are required at launch (Step 16), and discovering access problems on launch day creates delays and client frustration. Resolve access now, while there is time to recover.

Domain Registrar Access

Ask the client: "Who manages your domain — where did you originally register it?" Common registrars include GoDaddy, Namecheap, Google Domains (now Squarespace), Network Solutions, and Bluehost. Once identified, the client needs to either share login credentials or add you as an authorized user.

What to Document

If the Client Uses Cloudflare

Some clients already have their domain on Cloudflare. If so, the DNS changes at launch are made in the Cloudflare dashboard instead of the registrar. Confirm whether Cloudflare is being used and document the login credentials accordingly.

New Domains

If the client does not have a domain yet, register one on their behalf through Namecheap or Cloudflare Registrar. Use the client's business name as the basis for the domain. Confirm the domain with the client before purchasing. Document the registrar login credentials immediately after registration.

The SEO strategy produces the keyword-city matrix that drives the site architecture. Every service page and location page built in Step 6 corresponds to a row in this matrix. The strategy must be completed before the build begins — it is not optional and it is not done after the fact.

How to Run the SEO Strategy

Navigate to the SEO Portal at seo.dotcomdesignops.com and click "Build New Strategy." Enter the client's website URL and plan level. The system will run automatically and produce a live strategy site within 5 minutes. The full process is documented in the SEO Operations Playbook.

What the Strategy Produces

Plan Levels Reference

The build brief is the single document that drives the entire Manus build session. A well-written brief produces a site that needs minimal revision. A vague or incomplete brief produces a site that requires multiple revision loops. Invest the time here — it pays back tenfold in Step 6.

Brief Anatomy

The brief has eight required sections. Every section must be completed before opening the Manus build task. Do not start the build with a partial brief.

AI Friendliness Data Requirements

The following data points must be collected during the KO call or from the client before the brief is written. These are required to pass the AI Friendliness audit at Step 11 without any rework. If any of these are missing, the brief is incomplete.

Build Prompt Template

See the Build Prompt Template in the Appendix for the full fill-in template. Copy it, fill in every field, and use it as the opening message in your Manus build task.

Opening the Manus Task

Before submitting the brief, read the Multi-Agent Workflow page in the Appendix. It contains the exact opening prompt to paste at the start of every Manus build session, which loads the correct skills and sets the right context before the brief is submitted.

The site build is executed entirely inside Manus using the static site stack (HTML, CSS, vanilla JS). Manus builds the full site based on the brief. Your role during the build is to review output as it comes in, catch issues early, and provide corrections before the full site is assembled.

Build Stack

All client websites are built as static HTML/CSS/JS sites deployed to Cloudflare Pages. This is the only acceptable stack. Do not use WordPress, Webflow, Squarespace, Wix, or any other CMS. Do not use React, Vue, or any JavaScript framework. The site must be pure static HTML.

Required Pages

Every site must include the following pages at minimum. Additional pages are added based on the SEO matrix from Step 4.

Homepage SOP

The homepage must contain all of the following sections in this order. Manus will build them — this list is your review checklist.

1. Navigation bar — Logo, all main nav links, phone number as a CTA button. Must be sticky on scroll.
2. Hero section — Headline with primary keyword, subheadline, primary CTA button (phone), secondary CTA (contact form). Background image or strong visual.
3. Trust bar — Years in business, license number, service area, key differentiators. Displayed as icon + stat pairs.
4. Services overview — Grid of service cards. Each card links to the corresponding service page.
5. About teaser — 2–3 sentences about the company, photo of owner or team, link to full About page.
6. Gallery teaser — 3–6 photos in a grid. Link to full Gallery page. Skip if no photos available.
7. Testimonials — 3–5 testimonials. Star ratings if available. Source attribution (Google, etc.).
8. Service area map or list — Either an embedded Google Map or a list of cities served.
9. Contact CTA section — Final call to action with phone number and link to contact form.
10. Footer — Logo, nav links, phone, address, hours, copyright, license number.

Mobile SOP

Every page must be fully responsive. The following mobile-specific requirements apply to every build. These are not optional — they are checked in Step 7 (Visual QA).

Mobile Excellence SOP

The Mobile SOP above defines the minimum requirements. The Mobile Excellence SOP defines what it means for a site to actually function like a mobile website — not just one that fits on a phone. Every build must meet both the minimum SOP and the excellence standard. Manus must apply these without being asked.

Interior Page SOP

All service pages and location pages follow the same interior page structure. Manus builds these automatically from the SEO matrix. Review each one against this structure. Interior pages must also meet the visual design standards below — a page that passes the structure checklist but looks like a plain text document is not acceptable.

1. Page hero — H1 with the exact keyword + city (e.g., "Roofing Contractor in Omaha, NE"). Subheadline. CTA button. Hero must use a relevant, high-quality image specific to the service — not a generic stock photo. The image must show the actual type of work (e.g., a masonry photo for a masonry page, not a generic construction worker).
2. Intro section — 2–3 paragraphs of unique copy about this service or location. Must not be copied from another page. Copy must be broken into short paragraphs — no walls of text.
3. Services list — Styled cards or icon+text pairs, not a plain bulleted list. Each item has a short title and 1–2 sentence description. Minimum 3 items.
4. Why choose us — 3–4 differentiators in a visually distinct layout (icon grid, numbered list with large numbers, or alternating image/text). Must not look identical to the services list.
5. Gallery or photo — At least one relevant image. Use a gallery if photos are available. Images must have descriptive alt text.
6. Testimonial — At least one testimonial in a styled blockquote or card. Include star rating, reviewer name, and source (Google, etc.). Must not be plain text.
7. Contact CTA — A visually distinct section with brand background color, phone number in large type, and a button linking to the contact form. Must not be a plain paragraph.
8. FAQ section — 3–5 FAQs in a styled accordion (not a plain list). Each question is a clickable toggle. These become FAQ schema in Step 9.
9. Internal links — At least 2 links to related service pages or location pages, styled as text links or a "Related Services" card row.

Gallery SOP

If the client has 6 or more photos, a gallery page is required. The gallery must meet the following standards.

AI Friendliness Build Requirements

Every site must score 32/32 on the DD AI Audit Tool at launch. This is not a target — it is the standard. These 32 requirements are build requirements, not audit items. Implement every one during the initial build so the audit at Step 11 is a confirmation pass, not a rework session. The only documented exception is the readability factor (Flesch-Kincaid), which may score partial due to trade terminology — this is acceptable and expected.

Pillar 1: Technical Infrastructure (7 factors)

Pillar 2: Content Structure & Extractability (12 factors)

Pillar 3: Entity & Authority Signals (8 factors)

Pillar 4: Strategic AI Assets (5 factors)

Visual QA is a systematic page-by-page review of the site at three viewports: mobile (375px), tablet (768px), and desktop (1200px). Every page is checked. No page is skipped. Issues found here are fixed before moving to Technical QA.

Visual QA Checklist — Every Page

Run this checklist on every page of the site. Check all three viewports for each item.

Homepage-Specific Checks

Technical QA checks the underlying code and infrastructure of the site — things that are invisible in a visual review but affect performance, accessibility, and search engine indexing. Run these checks against the live preview URL.

Technical QA Checklist

The SEO readiness audit verifies that every on-page SEO element is correctly implemented before the site goes live. This is the last opportunity to catch missing schema, incorrect meta titles, or missing keywords before the site is indexed.

On-Page SEO Checklist

Schema Validation

After confirming schema is present in the source, validate it using Google's Rich Results Test at search.google.com/test/rich-results. Paste the preview URL and confirm no errors are returned for LocalBusiness and FAQ schema.

Run PageSpeed Insights on the homepage and at least two interior pages. The target score is 90+ on both mobile and desktop. If the score is below 90, identify the failing items and fix them before proceeding.

PageSpeed Insights

Run the test at pagespeed.web.dev. Test the homepage, one service page, and one location page. Record all four scores (Performance, Accessibility, Best Practices, SEO) for each page.

Score Targets

Common Performance Fixes

AI search engines (ChatGPT, Perplexity, Google AI Overviews) are increasingly the first point of discovery for local services. An AI-friendly site is structured so that AI systems can accurately extract and cite business information. This step ensures the site is optimized for AI discoverability in addition to traditional search.

AI Friendliness Checklist

AI Friendliness Score Audit

In addition to the manual checklist above, run the site through the Dotcom Design AI Friendliness Auditor at ai-audit.dotcomdesignops.com. This is DD's proprietary tool — it audits all 32 on-site AI Friendliness factors across 4 pillars, provides a pass/needs-work/fail verdict per factor, and generates actionable fix instructions. The score is reported as X/32 factors passing.

The 32 Factors — Build Requirements by Pillar

Every factor below must be addressed during the initial build in Steps 5–8. If the build brief, build prompt, and these requirements are followed, the site should pass all 32 factors at audit time with zero rework required. Run the full audit at ai-audit.dotcomdesignops.com.

🔧 Pillar 1: Technical Infrastructure (7 Factors)

📝 Pillar 2: Content Structure & Extractability (12 Factors)

🏆 Pillar 3: Entity & Authority Signals (8 Factors)

🤖 Pillar 4: Strategic AI Assets (5 Factors)

llms.txt Template

Create a file at /llms.txt with the following structure, filled in for the client:

# [Business Name]

[Business Name] is a licensed [trade] contractor based in [City, State].
We serve [primary service area] and surrounding communities.

## Services
[List all services, one per line]

## Service Area
[List all cities served, one per line]

## Contact
Phone: [phone number]
Address: [full address]
Hours: [business hours]
Website: [domain]

## About
[2-3 sentences about the business: years in business, owner name, mission]

## License & Insurance
[License number, bonding status, insurance status]

Content QA is a final human review of all copy on the site before the client sees it. This step catches factual errors, tone inconsistencies, and AI-generated copy that sounds generic or inaccurate. You are reading every page — not skimming.

Content QA Checklist

Before sending the site to the client for review, deploy it to a Cloudflare Pages preview URL. This gives the client a real browsing experience — not a screenshot or a Manus preview link. The preview URL is what you send in the client review email.

Deployment Steps

1. Push the final site files to the client's GitHub repo under dotcomdesigniowa
2. Confirm the Cloudflare Pages project is connected to this GitHub repo and auto-deploys on push
3. Wait for the Cloudflare Pages build to complete (typically 1–2 minutes)
4. Copy the Cloudflare Pages preview URL (format: https://[project].pages.dev)
5. Test the preview URL in an incognito window to confirm it loads correctly
6. Test on a real mobile device if possible

Cloudflare Pages Setup (First Time)

If this is the first deployment for this client, create the Cloudflare Pages project before pushing. Connect it to the GitHub repo, set the build command to blank (static site — no build step), and set the output directory to / (root).

Process Flags — Automated Marker.io Registration

After confirming the Cloudflare Pages build is live, call the In Flight /api/deploy-preview endpoint. This single API call automatically handles all of the following — no manual steps required:

1. Creates a new Marker.io website project using the Cloudflare Pages preview URL
2. Registers the new project on the Process Flags webhook (fires on every Bug-type issue submitted via the Marker.io widget)
3. Saves the Marker.io project ID and preview URL to the In Flight project record
4. Logs the completion of Step 13 in the project activity log

POST https://hub.dotcomdesignops.com/api/deploy-preview
Content-Type: application/json

{
  "projectSlug": "[in-flight-project-slug]",
  "previewUrl": "https://[cloudflare-project-name].pages.dev",
  "apiKey": "dd-ko-2024"
}

The endpoint is idempotent — if the project already has a Marker.io ID registered, it returns the existing data without creating a duplicate. At Step 16 (Go Live), call /api/go-live with the live custom domain to automatically update the Marker.io project URL from the preview URL to the live domain.

Send the preview URL to the client with clear instructions on how to review it and what to look for. Set a 48-hour response window. If no response is received within 48 hours, follow up once. If no response after 72 hours, proceed to Step 15 with zero revisions.

Client Review Email Template

Subject: Your New Website Is Ready for Review — [Business Name]

Hi [Client Name],

Your new website is ready for your review! Please take a look at the
preview link below and let us know if you have any changes.

Preview Link: [CLOUDFLARE PAGES URL]

How to review:
- Check all pages using the navigation menu
- Review on both your phone and your computer
- Check that all your services, contact info, and hours are correct
- Note any text changes, photo swaps, or additions you'd like

Please send all feedback by [DATE — 48 hours from now]. We'll make
your requested changes and then proceed to launch.

If everything looks great and you're ready to go live, just reply
with "Approved" and we'll schedule the launch.

[Your name]
Dotcom Design

Scope of Revisions

The client is entitled to one round of revisions as part of the build. Revisions include text corrections, photo swaps, and minor layout adjustments. Revisions do not include adding new pages, changing the design direction, or rebuilding sections from scratch. If the client requests out-of-scope changes, note them as a separate project.

Implement all in-scope client revisions. After implementing, re-run Visual QA (Step 7 checklist) on any pages that were changed. Do not skip the re-check — revisions sometimes introduce new issues. Once revisions are complete and re-checked, get client approval before proceeding to launch.

Revision Process

1. Work through the revision list item by item in Manus
2. After all revisions are made, push to GitHub and confirm the Cloudflare Pages preview updates
3. Re-run Visual QA on all changed pages
4. Send the updated preview URL to the client with a note that revisions are complete
5. Request final approval: "Please reply with 'Approved' to proceed to launch"

Go Live connects the client's domain to the Cloudflare Pages deployment. DNS propagation typically takes 5–30 minutes but can take up to 48 hours in rare cases. Do not schedule a launch for Friday afternoon or before a holiday weekend.

Launch Sequence

1. In Cloudflare Pages, add the client's custom domain to the project (Settings → Custom Domains)
2. Cloudflare will provide the DNS records needed (typically a CNAME pointing to pages.dev)
3. Log into the client's domain registrar (from Step 3 credentials)
4. Add the CNAME record provided by Cloudflare Pages
5. If the domain uses Cloudflare DNS already, the record is added automatically — just confirm
6. Wait 5–30 minutes for DNS propagation
7. Test the live domain in an incognito window: confirm the site loads, HTTPS is active, and no redirect loops
8. Submit the sitemap to Google Search Console: https://search.google.com/search-console
9. Request indexing for the homepage in Google Search Console

Process Flags — Automated Marker.io URL Update

After DNS is confirmed and the site loads on the live domain, call the In Flight /api/go-live endpoint. This automatically updates the Marker.io project URL from the Cloudflare Pages preview URL to the live custom domain, ensuring the Marker.io widget is correctly associated with the production site.

POST https://hub.dotcomdesignops.com/api/go-live
Content-Type: application/json

{
  "projectSlug": "[in-flight-project-slug]",
  "liveUrl": "https://clientdomain.com",
  "apiKey": "dd-ko-2024"
}

Post-DNS Checks

Within 24 hours of launch, set up uptime monitoring and verify that Google has begun crawling the site. These steps take 30 minutes but provide ongoing protection and early warning of any issues.

Monitoring Setup

48-Hour Check

Return to the site 48 hours after launch and run the following quick checks:

1. Homepage loads correctly — no errors
2. Contact form still submits correctly
3. Google Search Console shows no new coverage errors
4. UptimeRobot shows 100% uptime since launch
5. Run a quick Google search for the business name — confirm the new site is indexed or indexing is in progress

The Google Business Profile (GBP) must be updated to reflect the new website and any information changes made during the build. NAP consistency between the website and GBP is a critical local SEO signal. This step is not optional.

GBP Update Checklist

The Quarterback Handoff transfers ownership of the client relationship from the build team to the ongoing account management team. The quarterback is responsible for the client's ongoing SEO, reporting, and relationship management. A complete handoff ensures nothing falls through the cracks.

Handoff Package

Prepare and deliver the following to the quarterback before this step is complete:

Ongoing maintenance is the quarterback's responsibility from this point forward. The build team is no longer the primary contact. This page documents the recurring maintenance tasks that must be performed on every active client site.

Monthly Maintenance Tasks

Handling Update Requests

When a client requests a content update (new photos, changed hours, new service), the quarterback opens a new Manus task, provides the specific change request, and pushes the updated files to GitHub. Cloudflare Pages auto-deploys within 2 minutes. The client is notified when the update is live.

Process Flags Closed-Loop Workflow

Process Flags are observations submitted via the Marker.io widget during the build and review phases of new-process sites. They are not client bugs — they are internal signals that the Playbook or build system needs improvement. The closed-loop workflow below ensures that every Process Flag eventually results in either a Playbook update or a documented decision to take no action.

Every site we build must be beautiful. This is not a subjective aspiration — it is a defined, measurable standard. A site that passes all four audits (W3C, WAVE, PageSpeed 100, AI Friendliness) but looks generic or amateur does not meet the Dotcom Design standard. This page defines exactly what beautiful means so Manus can apply it consistently without being asked.

Typography Pairing Rules

Every site must use a two-font system: one display font for headings and one body font for paragraph text. Never use a single font for both roles. Never use more than two font families on a single site.

Spacing Scale

All spacing (padding, margin, gap) must come from a fixed scale. Do not use arbitrary values like 13px or 37px. Consistent spacing is what separates professional design from amateur design.

Color Application Rules

Every site has three color roles: Primary (brand action color), Neutral (backgrounds and text), and Accent (optional secondary highlight). These rules govern how color is applied across the site.

Component Quality Benchmarks

These are the minimum visual quality standards for each major component type. A component that is functional but does not meet these benchmarks must be redesigned before the site passes Visual QA.

The "Beautiful" Checklist

Before marking Visual QA complete, verify every item below. This checklist is the definition of "beautiful" for a Dotcom Design site.

Cloudflare

GitHub

Formspree

Marker.io Webhook — In Flight Process Flags

Every new website build starts with a new Manus task. The opening prompt is critical — it loads the correct skills and sets the right context before the brief is submitted. Use the exact prompt below at the start of every build session.

Opening Prompt

Copy and paste this as the very first message in every new Manus build task. Replace the bracketed fields with the client's information.

You are building a client website for Dotcom Design.

Before doing anything else, read the following skills:
1. /home/ubuntu/skills/dd-playbook/SKILL.md
2. /home/ubuntu/skills/dotcom-design-brand/SKILL.md
3. /home/ubuntu/skills/static-site-launch-optimizer/SKILL.md

After reading all three skills, confirm you have read them and are
ready to receive the client brief.

Client: [CLIENT BUSINESS NAME]
Build type: Static HTML/CSS/JS website
Hosting: Cloudflare Pages
Stack: Pure HTML, CSS, vanilla JS — no frameworks, no CMS

After the Opening Prompt

Wait for Manus to confirm it has read all three skills. Then submit the full client brief (all eight sections from Step 5). Do not submit the brief in the same message as the opening prompt — send them separately so Manus has time to load the skills before processing the brief.

During the Build

Stay engaged during the build. Review each page as Manus builds it. Catch issues early rather than waiting for the full site to be assembled. If Manus produces something that does not match the brief, correct it immediately with a specific instruction rather than waiting until the end.

Useful Mid-Build Commands

This is the full client brief template. Fill in every field before submitting to Manus. Do not leave any field blank. Submit this as the second message in the Manus task, after the opening prompt has been acknowledged.

## CLIENT BRIEF

### SECTION 1: BUSINESS IDENTITY
Business Name (exact): 
Phone Number: 
Address: 
City, State, ZIP: 
Business Hours: 
  Monday: 
  Tuesday: 
  Wednesday: 
  Thursday: 
  Friday: 
  Saturday: 
  Sunday: 
Years in Business: 
License Number(s): 
Bonded: Yes / No
Insured: Yes / No

### SECTION 2: SERVICE AREA
Primary City: 
All Cities/Counties Served: 
HQ City (for schema): 

### SECTION 3: SERVICES
Primary Services (most important first):
1. 
2. 
3. 
4. 
5. 

Secondary Services:
1. 
2. 
3. 

### SECTION 4: DESIGN DIRECTION
Design Sliders (1-10):
  Style (Classic → Modern): 
  Tone (Light → Dark): 
  Complexity (Simple → Rich): 
  Voice (Friendly → Authoritative): 
  Market Position (Economical → Premium): 
  Aesthetic (Polished → Gritty): 

Reference Site URL (a site they like): 
Color Preferences (if any): 
Font Preferences (if any): 

### SECTION 5: CONTENT ASSETS
Logo File Location: 
Photos Available: Yes / No
  If Yes, count: 
  If Yes, location: 
Testimonials:
  1. "[text]" — [Name], [Source]
  2. "[text]" — [Name], [Source]
  3. "[text]" — [Name], [Source]
Team Members (if applicable):
  Name, Title, Bio: 

### SECTION 6: TRUST SIGNALS
Years in Business: 
License Number(s): 
Certifications/Awards: 
Industry Associations: 
Notable Differentiators: 

### SECTION 7: SEO MATRIX
[PASTE FULL KEYWORD-CITY MATRIX FROM SEO PORTAL HERE]

### SECTION 8: AI FRIENDLINESS DATA (Required for 90+ score at audit)
# Statistics — include ALL of these as real numbers in the page copy:
Years in Business: 
Jobs/Projects Completed: 
Warranty Length (if applicable): 
Response Time (e.g., "same-day estimates"): 
Service Count (total number of services offered): 
Any other notable stats (e.g., "5-star rated", "100% satisfaction guarantee"): 

# Citations — include ALL of these as external links in the site:
BBB Profile URL: 
Google Business Profile URL: 
License Verification URL (state licensing board): 
Industry Association URL (NARI, NAHB, etc.): 

# Schema — required fields for LocalBusiness schema:
Geo Latitude: 
Geo Longitude: 
Price Range (e.g., "$$"): 
Area Served (list all cities): 

# FAQ Questions — provide 4+ per service page:
Homepage FAQs:
  Q: 
  Q: 
  Q: 
  Q: 
Primary Service Page FAQs:
  Q: 
  Q: 
  Q: 
  Q: 

### SECTION 9: SPECIAL INSTRUCTIONS
[Any unique requirements, specific pages requested, content to preserve,
integrations needed, or anything else the build team should know]

---

## AI FRIENDLINESS BUILD INSTRUCTIONS — ALL 32 FACTORS
# These instructions are non-negotiable. Every item must be implemented
# during the initial build. The site must score 32/32 on the
# DD AI Audit at ai-audit.dotcomdesignops.com with zero FAIL factors.
# Standard: 32/32. Readability (Flesch-Kincaid) is the only factor where partial is acceptable due to trade terminology.

# ── PILLAR 1: TECHNICAL INFRASTRUCTURE (7 factors) ──────────────

1. AI CRAWLER ALLOW-LISTING: robots.txt must explicitly allow all AI bots:
   User-agent: GPTBot
   Allow: /
   User-agent: ClaudeBot
   Allow: /
   User-agent: PerplexityBot
   Allow: /
   User-agent: GoogleOther
   Allow: /
   User-agent: Anthropic-AI
   Allow: /
   Do NOT add noindex to any service page.

2. SERVER-SIDE RENDERING: All content must be in the initial HTML payload.
   No JavaScript-only rendering. Critical text must be visible without JS.

3. MOBILE PAGE SPEED: Target 90+ PageSpeed mobile score.
   - Use WebP images with explicit width/height attributes
   - Inline critical above-fold CSS
   - Self-host fonts (no Google Fonts CDN blocking)
   - All scripts use defer or async

4. HTTPS: Cloudflare Pages provides HTTPS automatically. Verify before delivery.

5. XML SITEMAP: sitemap.xml must exist at /sitemap.xml listing all pages.
   Add to robots.txt: Sitemap: https://[domain]/sitemap.xml

6. RENDER-BLOCKING: All scripts use defer or async. No synchronous
   third-party scripts in . No @import in CSS.

7. INTERNAL LINKING: All links use proper href URLs. No javascript:void().
   Use  for JS actions,  for navigation only.

# ── PILLAR 2: CONTENT STRUCTURE & EXTRACTABILITY (12 factors) ───

8. ANSWER-FIRST STRUCTURE: Every section opens with a direct declarative
   statement. "We build brick, block, and concrete structures" — not
   "Are you looking for a contractor?"

9. HEADING HIERARCHY: Exactly one H1 per page. H2 for sections. H3 for
   sub-items. Never skip levels (no H1 to H3 without H2).

10. DATA-DRIVEN STATISTICS: Use the numbers from Section 8 on every page.
    Never write "years of experience" without the number.
    Never write "many projects" — use the actual count.
    Include: years in business, projects completed, response time, service count.

11. NUMBERED LISTS FOR PROCESSES: All "How It Works" and step-by-step
    content must use 
 tags. Never use plain paragraph text for
    sequential steps.

12. BULLET POINTS FOR FEATURES: All feature lists, service benefits, and
    key characteristics must use 
 tags.
    Minimum 2 lists per page with 4+ items each.

13. COMPARISON TABLES: At least one HTML  per site (service
    comparison, material options, or pricing tiers). Use proper
    //
/
 markup.

14. SHORT PARAGRAPHS: All paragraphs must be 2-4 sentences maximum.
    One idea per paragraph. Use subheadings to break up long sections.

15. EXECUTIVE SUMMARIES: Homepage and service pages must include a
    "Quick Facts" or "At a Glance" section near the top:
    who, what, where, why — in 3-5 bullet points.

16. FAQ SECTIONS: Every page must have a FAQ section with minimum 5
    questions as H2/H3 headings with direct answers.
    Apply FAQPage JSON-LD schema. Questions must be natural language.

17. ACTIVE VOICE: Write "We install" not "Installation is provided."
    Write "Call us" not "We can be reached by calling."
    Review all copy before delivery.

18. CLEAR DEFINITIONS: First paragraph of every service page must define
    the service in plain language.
    Example: "Tuckpointing is the process of removing damaged mortar from
    brick joints and replacing it with fresh mortar."

19. COMPREHENSIVE SERVICE DETAILS: All services, specialties, service area
    (list every city/county), and credentials must appear in plain HTML
    text — not images or JavaScript.

# ── PILLAR 3: ENTITY & AUTHORITY SIGNALS (8 factors) ────────────

20. SCHEMA MARKUP: Required JSON-LD on every page:
    - LocalBusiness/Contractor with ALL fields:
      name, address, phone, geo (lat/lng), hours, priceRange,
      areaServed (list all cities), url, sameAs (GBP, BBB, Angi)
      datePublished, dateModified (set to today)
    - FAQPage on every page with a FAQ section
    - BreadcrumbList on all interior pages
    - Person schema for business owner (on About page and homepage)

21. AUTHOR PROFILES: About page must include owner name, photo, years of
    experience, credentials, and personal story. Required for E-E-A-T.

22. AUTHOR SCHEMA (Person): Person JSON-LD for the business owner:
    name, job title, description, sameAs (social profiles).
    Add to About page and homepage schema.

23. CITATIONS: Every page must include 2+ external links to authoritative
    sources. Use the URLs from Section 8: BBB, GBP, licensing board,
    industry association, or manufacturer specs.

24. TEXT-BASED TRUST SIGNALS: All trust signals must appear as explicit
    HTML text — not badge images only. Write out:
    "Licensed & Insured", "BBB Accredited", "25 Years in Business".

25. CONTENT FRESHNESS: Schema must include datePublished and dateModified.
    Footer copyright year must be current year.

26. CONSISTENT NAP: Business name, full street address, city/state/ZIP,
    and phone number must appear in plain HTML text in the footer of
    every page. Must match Google Business Profile exactly.

27. EXPERT QUOTES: At least one direct quote from the business owner or
    lead craftsman on key pages. Attribute with name and title.
    Use 
 markup.

# ── PILLAR 4: STRATEGIC AI ASSETS (5 factors) ───────────────────

28. llms.txt FILE: Create /llms.txt with plain markdown:
    business name, description, all services, full service area,
    contact info, hours, FAQs. See llms.txt template in Step 11.

29. AI DISCLOSURE PAGE: Create an /ai page with comprehensive brand
    summary: all services with descriptions, full service area list,
    team bios, FAQs, and brand voice. Link in footer as "AI Info".

30. COMPETITOR COMPARISON: "Why Choose Us" section on homepage explicitly
    stating differentiators: years of experience, warranty, response
    time, local ownership, specific techniques or materials used.

31. VIDEO TRANSCRIPTS: If the site has embedded videos, all key
    information must also appear as text on the page.
    (N/A if no videos — mark as not applicable in audit notes.)

32. AI ATTRIBUTION IN FORMS: Contact form must include a
    "How did you find us?" dropdown with "AI Chatbot / AI Assistant"
    as one of the options. This tracks AI-driven leads.