SEO Playbook V2

Comprehensive baseline audit run via the standard audit sheet. Covers the full surface area of the site so we know what we're walking into.

• Website — crawl errors, indexation, redirect chains, canonical tags, robots.txt, sitemap
• Google Business Profile — completeness, categories, reviews, photos, citation consistency
• CMS — platform review, plugin/theme issues, URL structure
• Meta tags — page titles, meta descriptions, H1s, H2s across key pages
• Images — file names, alt text, file size and compression
• Page speed — Core Web Vitals, mobile performance, server response time
• Everything else — schema markup, internal linking, SSL, mobile-friendliness

Tools: Screaming Frog (or Sitebulb), Google Search Console, Google Analytics, PageSpeed Insights / Lighthouse, the standard IM audit sheet.

The audit sheet must be completed in full — no blank rows, no "TBD" placeholders. Every issue surfaced needs a severity (Critical / High / Medium / Low) and a recommendation. Critical issues must be flagged for the kickoff call so the client knows what we're doing first.

Crawls run on the full site, not just the homepage or top nav. Mobile and desktop both checked.

Completed audit sheet (saved to the client's Drive folder and committed to the per-client Git repo once that workflow is in place). A short summary document for the client highlighting the top 3–5 priorities and the planned action sequence.

This is the foundation that sets up every subsequent month of work. Without it we're guessing at priorities and the client can challenge our recommendations. Skipping it means we end up reactive — fixing what the client noticed instead of what's actually hurting performance, and we have no baseline to point back to in 6 months when the client asks "what have you actually done?"

Identify the keywords the client should rank for, based on their services, location, and competitive set. Map search volume, difficulty, and intent. Separate quick-win opportunities (low difficulty, decent volume, commercial intent) from long-term targets.

Tools: DataForSEO, Google Keyword Planner, Search Console, competitor SERP analysis, Serper API for keyword suggestions.

Output is a working keyword list, not a dump. Each keyword has: search volume, KD/difficulty, intent (informational / commercial / navigational), current rank (if any), and a target landing page. Branded keywords are separated from non-branded. Local modifiers (suburb, city) are included for local-SEO clients.

Keyword research spreadsheet (one row per keyword) saved to the client's Drive folder. Top 20 priority keywords flagged for the page mapping task that follows.

Everything downstream (page mapping, content roadmap, on-page optimisation) keys off this. Get this wrong and we'll spend months optimising for keywords nobody searches for. The quarterly refresh exists because keyword landscapes shift — new trends, competitor moves, AI-overview cannibalisation. Without the refresh we drift.

Map the priority keywords from research onto existing landing pages. Identify the gaps where new pages need to be created. Prioritise pages for initial optimisation work (Phase 2).

Each existing page gets one primary keyword and 2–4 supporting keywords. Conflicts (two pages targeting the same primary) get resolved here, not later.

Every priority keyword has either a mapped existing page or a flagged gap (with a proposed URL/title). No keyword sits unmapped. Cannibalisation issues — multiple pages competing for the same query — are surfaced and resolved (consolidate, redirect, or differentiate).

Page mapping sheet — keyword to URL, with primary/supporting designation. New page proposals listed separately so they can be picked up by the content roadmap. Saved to the client's Drive folder.

This is the plan that makes monthly on-page optimisation efficient. Without it, the team optimises whatever feels important that month, two pages end up fighting for the same keyword, and rankings stall. The mapping is the single source of truth for "which page targets what" — sales, content, and SEO all reference it.

Submit the client's NAP (Name, Address, Phone) details to core local directories. Volume scales with tier — 50 citations is the standard initial build for a Premium client. Lower tiers get a smaller core set.

Audit existing listings before submitting new ones to avoid duplicates.

NAP must be 100% consistent across every directory — same business name, same address format, same phone number. Inconsistency is what tanks local rankings. Categories are matched to GBP. Submission confirmations are kept (screenshots or emails).

Citation tracking sheet listing every directory submitted to, with: submission date, status (live / pending), URL of the listing once live, and any inconsistencies found and resolved. Saved to the client's Drive folder.

Local search rankings depend heavily on citation volume and consistency. Without a baseline citation build, local rankings stall regardless of on-page work. Flagged for automation — at 8 hours per client this is one of our biggest time sinks; reducing it is a priority.

Create the brand's page.md (or equivalent) file that gives AI tools structured context about the business — services, locations, key pages, brand voice, target audience. This is the AI-era equivalent of a brand guidelines doc but written for machines.

Covers: business overview, services list, target locations, key URLs (services, contact, about), USPs, recent press / awards, brand tone. Concise — this is for AI consumption, not a marketing brochure.

page.md file in the site root (or equivalent location for the CMS). Copy committed to the client's Drive folder for reference.

AI tools (ChatGPT, Gemini, Perplexity) increasingly drive discovery. Without a structured context file, the AI guesses — often wrongly — about what the business does. This is fast, cheap, and quietly valuable. Pairs with llms.txt in the AIO quarterly task.

Per-page audit of the main landing pages (typically the top 5–10 service / category pages). For each page, document the specific changes needed: meta title rewrite, meta description rewrite, H1 fix, H-tag hierarchy fix, content additions, internal link insertions, schema additions.

This is the spec sheet that drives subsequent on-page work — it's not the optimisation itself.

One row per change, per page. Each row has: current state, proposed state, and rationale (which keyword / which audit finding it addresses). Bulk recommendations like "rewrite all H1s" don't count — each page gets its specific recommendation.

Page tweaks spreadsheet. One tab per page or one row per change — team's choice. Hands off to whichever team member is doing the on-page implementation.

This is the bridge between research and execution. Without it, the implementer makes their own judgement calls per page and the work drifts off-keyword. A well-mapped page tweaks sheet means the implementer can move fast and consistently — and it gives the client a clear "before / after" record of what we changed.

Liam's worked example from the 31 March meeting: "page tweaks mapping — 3 to 5 hours for an average site, covering main landing pages. New hires may take longer first time, but the documented range is the benchmark."

Improve existing pages to rank better for their target keywords. This is distinct from content creation — you are working with pages that already exist, not building from scratch. The process runs in three phases with a user review gate between each.

Every client has a content optimisation template (content-optimization-template.md) that governs all rules — expansion caps, tone, forbidden phrases, what can and cannot be rewritten. Read the Monthly Client Feedback Log in that template before starting; it carries forward rules from previous batches.

Phase 1 — Find & Extract: Pull GSC data (last 90 days) to identify the 5 best pages to optimise — prioritising position 5–20 pages with strong impressions. Check the client's Zoho project for recent feedback comments and append any new ones to the template before proceeding. Extract each page's current content verbatim (with inline links preserved) into local .md files. Pause Point 1: confirm the page selection before any optimisation begins.

Phase 2 — Optimise: For each extracted page: research target keyword from the client's keyword sheet (competitor research as fallback), analyse the current page structure, write optimised content following the template rules. Key constraints: preserve all original content — only add or refine, never delete; mark all additions in bold; stay within the word-count expansion cap in the template; no keyword stuffing; natural anchor text on internal links. Run a 6-gate verification pass on every file before presenting results. Pause Point 2: review optimised files before upload.

Phase 3 — Upload to Google Docs: Create one fully-formatted Google Doc per optimised file in the client's Google Drive "Page Optimisation" folder. Verify highlights and completeness. Update the tracking sheet. Generate the Zoho upload script for handoff. Pause Point 3: confirm docs before marking task complete.

Original content preserved in full — additions bolded so implementers can see exactly what changed. Target keyword in H1, first 100 words, and at least one H2. Meta title and description rewritten to spec (55–60 chars / 150–160 chars). Internal links use descriptive anchor text. No content deleted without explicit instruction. Word count expansion within the cap defined in the client template. All 6 verification gates passed before upload.

Google Docs in the client's Drive "Page Optimisation" folder — one doc per page, fully formatted with additions highlighted. Tracking sheet updated. Zoho task comment with doc links, word count deltas, and a note on any constraints applied (e.g. "capped at 200 words per template rule"). Do not mark the task complete without the Zoho handoff comment.

The highest-leverage recurring task — moving a page from position 11 to position 6 typically more than doubles its click-through rate. Rankings are not static: competitors update their pages every month, and pages that are not actively maintained drift down. The monthly cadence and the 3-phase process exist to make this systematic rather than ad hoc. Skipping a month means the next month is twice the work and the client has already lost traffic.

Build a forward-looking content plan — blog topics, new service pages, FAQ content, supporting / pillar pages. Sourced from: keyword gaps in the page mapping, competitor content gap analysis, GSC opportunity queries, client business priorities.

Each topic has: target keyword, search volume, intent, proposed format (blog post / pillar page / FAQ / location page), proposed URL slug, and a one-line angle. Roadmap covers at least 3 months ahead.

Content roadmap spreadsheet with prioritised topics. Quarterly review updates priorities based on what's been published, what's ranked, and what's now relevant.

Without a roadmap, content gets written reactively and we miss strategic opportunities. With one, every piece of content is defensibly chosen ("we wrote this because the keyword has 1,200 searches and our competitor ranks for it but we don't"). The quarterly review is critical — reality always diverges from the plan.

Produce a new SEO-optimised blog post from scratch following a four-phase process: keyword and competitor research, structured outline, written article with fact-checking, then internal links and SEO metadata. Every client has a brand template (blog-content-creation-template.md) that governs all content rules — voice, forbidden words, CTA language, English variant, and keyword targets. The template is the single source of truth; read it in full, including the Monthly Feedback Log, before starting.

Phase 1 — Research: Derive keyword set (primary, 2–3 secondaries, 2–4 longtails, brand keyword), analyse top 5 ranking competitors, build synthesis table, identify mandatory content areas and differentiation gaps. Save research report. Pause Point 1: confirm keyword set before outlining.

Phase 2 — Outline: Write H1 (primary keyword required), plan 4–6 H2s (at least 2 as questions), add H3s under every H2, assign word estimates per section (total 800–1,100), plan CTA and preliminary link placements. Pause Point 2: outline must be approved before writing begins.

Phase 3 — Write & Fact-Check: Fill the approved outline. Paragraphs max 4 lines and 3 sentences. No em dashes, no body bolding. Fact-check every material claim against a primary source — remove or qualify anything unverified. Run full self-validation checklist. Pause Point 3: approved draft required before linking.

Phase 4 — Links & Metadata: Propose 3–5 internal links (proposal table first, approval required). Verify each link is live (200/301/302) before inserting. Write the "For the SEO Team" metadata block at the top of the file. Final read-through for placeholders, broken sentences, and English variant. Pause Point 4: link plan approved before insertion.

Primary keyword 8–12 uses; each secondary 2–3 uses; longtails 2–4 total; brand 3–5 uses. No keyword repeated in the same paragraph. H1 contains primary keyword. Text between H1 and first H2 (min 2 sentences) and between every H2 and its first H3. Every H2 has at least one H3 beneath it. No paragraph exceeds 4 lines. No em dashes. No bolding in the article body. CTA uses consultative language. All internal links verified live. All material claims fact-checked against a primary source. Page title 55–60 chars; meta description 150–160 chars; slug lowercase hyphens only.

Final article at {client}/blog-content/{topic-slug}-BLOG.md with "For the SEO Team" metadata block at top. Content notes at {client}/contentnote/{topic-slug}-BLOG-NOTES.md. Competitor research report in {client}/reports/seo-research/. All four pause points completed. Zoho task updated with file path, word count, quality score, and a note on any claims removed or qualified.

New content captures keywords existing pages can't reach. Consistent publishing signals to search engines that the site is active — sites that publish regularly are crawled more frequently and recover faster from algorithm shifts. A well-researched article with correct keyword focus and verified claims builds compounding traffic over time; thin or mis-targeted content dilutes topical authority and wastes the client's budget.

Identify and fix internal links on the client's website that point to broken (404) or redirected URLs.

In scope:

• Crawl the site (Screaming Frog, Sitebulb, or Ahrefs Site Audit) to surface 404s and redirect chains on internal links.
• For each broken internal link: update to the correct live URL, replace with a relevant alternative, or remove if no alternative exists.
• For redirect chains: shorten so the link points directly to the final destination (no intermediate hops).
• Log the count of broken links found, count fixed, and any unfixable (with reason) in the Zoho task comment.

Out of scope: External broken links (separate task — Fix Broken Links (External)); broken images (covered under Image SEO Re-Audit); 5xx server errors (escalate to client's dev team).

• All internal 404s identified — the crawl must cover the full site, not just the homepage.
• All identified 404s either fixed, replaced, or documented as unfixable — no silent skips.
• Redirect chains shortened to a single hop wherever the destination is owned by the client.
• Per-page link audit, not just sitewide totals. A page with 20 broken links isn't "fixed" because we only repaired the first 5.
• Document everything — pre-fix count, post-fix count, what was changed, what couldn't be changed and why.

Updated client website (broken internal links resolved) plus a Zoho task comment containing: crawl date and tool used, total broken internal links found, number fixed, number unfixable + reason for each, time logged.

Example of a good Zoho comment:

"Fixed broken links — crawled with Screaming Frog 6 May 2026. Found 364 broken internal links across 47 pages. Fixed 351 (updated link target or removed). 13 unfixable: destination pages deleted by client during their March redesign; flagged in the content team's backlog. Took 4h 15m, ~1h over estimate due to deep nav structure on category pages. Time logged."

(Future) Snapshot of the broken-link list committed to the client's per-client Git repo so the diff between snapshots proves which links are new vs which were already fixed.

Why we do this:

• User experience — broken links cause user drop-off and tank dwell-time signals.
• Crawl budget — Google wastes crawl budget on 404s that could be spent on real pages.
• Internal link equity — broken links break the silo structure and stop authority flowing to important pages.
• Defensibility — the audit trail matters as much as the fix. The "difficult client" scenario: we fix 20 broken links. Three months later the client adds 50 pages and introduces 30 new broken links. Client accuses us of not fixing them. With the audit trail (and the per-client Git repo diff) we can prove: "these 20 are fixed; these 30 are new, introduced by your page additions on [date]." Without it, we look incompetent. This is why the documentation step is non-negotiable.

If we skip it: the client's site gradually accumulates 404s with each content update; rankings on category and pillar pages slowly degrade; and we have no defence when the client questions our work in three months.

Identify and fix outbound external links on the client's site that point to dead pages on third-party sites. Crawl with Screaming Frog (external link mode), validate each broken link, then either update to the new URL on the third-party site, replace with a different authoritative reference, or remove the link.

External links to authoritative sources (gov, edu, industry bodies) are preserved where possible — find a live equivalent rather than removing. Affiliate / sponsorship links require client sign-off before any change.

Updated live pages plus Zoho comment with: count found, count fixed, links removed (with rationale), links escalated to client (e.g. partner links).

External 404s are smaller scale than internal but they still erode user trust and waste authority. Less critical than internal, but free real estate — a 2-hour fix that shows up in any technical SEO audit the client runs against us.

Fix heading tag hierarchy across the site — missing H1s, multiple H1s on a single page, skipped levels (H1 to H3 with no H2), heading tags used for visual styling rather than structure.

One H1 per page. Hierarchy goes H1 → H2 → H3 with no skipped levels. Headings describe page structure, not visual size. H1 contains the target keyword where natural. CMS theme issues (e.g. site-wide template using H2 for the page title) are fixed at the template level, not page-by-page.

Updated pages live. If the fix was theme-level, note that in the Zoho comment so it's clear the change applied sitewide. Crawl re-run after fix to verify zero remaining hierarchy issues.

Heading hierarchy is how search engines (and screen readers) parse page structure. Broken hierarchy weakens topical relevance signals and creates accessibility issues. Sitewide fixes (when a theme uses the wrong tag everywhere) are particularly high-leverage — one change cascades across hundreds of pages.

Site-wide review and rewrite of meta titles, meta descriptions, and overall page structure (intro paragraphs, content blocks, CTA placement) for the main landing pages. This is the meta-tags counterpart to the page tweaks mapping but applied as a one-off across the site.

Every meta title is unique, under 60 characters, contains the target keyword and the brand. Every meta description is unique, 140–155 characters, sells the click. Page structure includes a clear intro, scannable subheadings, and a CTA above the fold.

Spreadsheet documenting all changes (current vs new meta title / description per URL). All changes applied to the live site. Saved to the client's Drive folder for sign-off and audit trail.

Meta titles and descriptions are the SERP ad copy — they drive click-through rate even when ranking position doesn't change. A 1% CTR improvement compounds across every impression. Also caught by every external SEO audit, so weak meta data is a credibility issue when clients run their own checks.

Audit GSC's Pages report — pages excluded from the index, "discovered – currently not indexed", "crawled – currently not indexed", noindex tags on pages that shouldn't have them, soft 404s, duplicate without canonical. Diagnose each and fix.

Every excluded URL has a verdict: should it be indexed (fix), or correctly excluded (leave). Common fixes: remove accidental noindex, add to sitemap, add internal links, rewrite thin content, set canonicals correctly.

Spreadsheet listing each excluded URL with verdict, action taken, and re-submitted via GSC's Validate Fix where applicable. Zoho comment summarises totals (e.g. "47 URLs reviewed; 23 reindexed via fix; 24 correctly excluded").

Pages that aren't indexed can't rank — full stop. Indexing issues often hide on otherwise healthy sites. Fixing this is among the cheapest wins in SEO: a page that was correctly written but quietly excluded suddenly ranks once we get it indexed.

Implement structured data (JSON-LD) on the 5 priority pages identified in page mapping. Schema types vary by page: LocalBusiness on the homepage / contact page, Service on service pages, Article / FAQPage on blog content, Product on product pages, BreadcrumbList sitewide.

Schema validates clean in Google's Rich Results Test (no errors, warnings reviewed). Properties are accurate (no fake review counts, no boilerplate descriptions). Schema reflects what's actually on the page — never schema-stuffing for properties that don't exist visibly.

Live schema deployed on the 5 pages. Validation screenshots saved in the client's Drive folder. Zoho comment includes the page URLs and schema types deployed.

Schema unlocks rich results (review stars, FAQ accordions, breadcrumb trails in SERPs) which substantially lift CTR. It also feeds AI overview eligibility — schema-rich pages are more frequently cited by Google's AI overview and by ChatGPT / Perplexity. The re-audit cadence matters because schema breaks easily when CMS templates change.

Audit Core Web Vitals via PageSpeed Insights / Lighthouse. Apply quick wins: enable caching, image compression, lazy-loading, plugin updates, remove render-blocking scripts. Larger fixes (theme rewrites, CDN setup) get scoped and proposed separately.

LCP under 2.5s, INP under 200ms, CLS under 0.1 on mobile for the homepage and at least one service page. If a quick win isn't possible (e.g. requires dev team), document the issue and proposed fix in the audit sheet.

Before/after PageSpeed scores for tested pages, saved to the client's Drive folder. Zoho comment lists the specific changes made (e.g. "enabled WP Rocket caching, compressed 47 hero images, deferred 3 third-party scripts").

Page speed is a confirmed ranking factor and a major UX driver — especially on mobile. Easy wins (caching, compression) often shift mobile scores 20+ points, and the work compounds with on-page optimisation. A fast site converts more of the traffic SEO drives.

Audit how internal links flow between pages. Identify orphan pages (zero internal links pointing to them), pages with too few internal links, and the silo / cluster structure. Add contextual internal links from related content into the priority landing pages.

Zero orphan pages on indexable URLs. Priority pages have at least 3 contextual internal links. Anchor text is descriptive and varied (not "click here" or always exact-match). Silo structure (parent → children) is intentional and visible in the URL hierarchy where possible.

Internal linking spreadsheet — orphan list with proposed fix, recommended new internal links per priority page, and documentation of the silo structure. Live changes applied across the site.

Internal links control how authority flows around the site. Orphan pages stall regardless of how good the content is. Strengthening internal linking on priority pages is one of the highest-leverage activities — no new content needed, just better wiring of what already exists.

Track keyword rankings (Rank Ranger), GSC metrics (impressions, clicks, CTR, queries), and GA (organic traffic, conversions). Spot trends — pages gaining or losing position, CTR drops, traffic shifts.

Month-on-month and year-on-year comparisons. Wins and losses both surfaced — a page that dropped from position 4 to 9 matters more than one that gained from 18 to 14. Findings feed into next month's plan.

Monthly performance summary (typically part of the client report) — top movers up, top movers down, traffic and conversion changes, recommended next actions.

This is what keeps SEO from being a black box for the client. It also catches problems early — a sudden drop in impressions might be a deindexing issue we need to fix this week, not next month. Without monitoring, we react late.

Use Google Trends, GSC opportunity queries (impressions but no clicks), and DataForSEO trends to surface emerging keywords in the client's space. Adjust the keyword map and content roadmap to chase them.

Distinguish seasonal (recurring annual) from genuinely new trends. Validate volume isn't already past peak. Map each trending keyword to either an existing page (optimise) or a proposed new piece of content.

Update to the keyword research sheet flagging trending opportunities. Additions to the content roadmap if a new piece is warranted.

The keyword landscape is not static. Catching a trend early is the difference between ranking on page 1 before competitors notice vs fighting for position 8 once everyone's writing the same article. Particularly valuable in fast-moving verticals (fashion, news-adjacent industries, tech).

Google Business Profile optimisation: profile completeness, category accuracy, photo refresh, GBP posts, Q&A monitoring, review responses, NAP consistency check, map embeds on the site pointing to the correct GBP listing. For multi-location clients, repeat per location.

Profile is 100% complete (no "add this" prompts). At least one new post per quarter. All reviews from the period responded to. Photos refreshed where stale. Categories reviewed against current offering.

Updated GBP profile(s). Zoho comment lists what was changed (categories adjusted, posts published, reviews responded to, photos uploaded). For multi-location clients, a per-location summary.

GBP is the dominant local-search surface — for many service businesses, the map pack drives more leads than the organic listing. Active profiles outrank inactive ones; stale profiles lose ranking even if their on-site SEO is excellent.

Re-run the meta tags review across the site to catch drift — meta titles the client edited without telling us, new pages with weak meta tags, descriptions that no longer match SERP intent. Same scope as the original Page Structure & Metadata Improvement task but applied as a cyclical check.

Same standard as the original optimisation: every meta title unique, under 60 characters, contains target keyword + brand. Every meta description unique, 140–155 characters, click-driving.

Diff sheet showing what changed since last audit, what we updated, and what remains correct. Saved to the client's Drive folder and (when in place) the per-client Git repo.

Meta data drifts. Clients edit pages, devs roll out theme changes, new pages get added without our review. Without a re-audit, the work we did at Phase 2 quietly degrades over the year. The cadence keeps quality at baseline.

Crawl images — file names, alt text, file size, dimensions. Catch new images uploaded without alt text, oversized files harming page speed, and missing descriptive file names (IMG_4738.jpg rather than melbourne-roller-shutters.jpg).

Every image on indexable pages has alt text (or an explicit empty alt for purely decorative images). File sizes under 200 KB for content images, under 100 KB for decorative ones. Descriptive file names where possible.

Image audit sheet listing images that needed fixing, what was fixed, what remains (e.g. images embedded by client where alt text needs CMS access). Updated alt text and compressed files live on site.

Images contribute to page speed (Core Web Vitals), accessibility (alt text), and image search traffic. Particularly relevant for product / portfolio sites where image search is a real traffic source. Often forgotten as the team focuses on text content.

Quick scan of GSC: Coverage / Pages report, Manual Actions, Security Issues, Mobile Usability, Core Web Vitals. Catch problems early before they become rankings problems.

Anything that's changed materially since last month gets investigated. New crawl errors are categorised: client-side (we can fix), server-side (escalate to client's host), or false-positive (note and ignore).

Zoho comment with the month's check summary — issues found, issues escalated, all-clear items. Anything urgent (manual action, indexing collapse) is flagged immediately, not held for the monthly report.

GSC tells us what Google sees. A monthly check is the cheap insurance against silent disasters — manual actions, indexing collapse from a robots.txt mistake, security warnings. Costs an hour. Saves entire client relationships.

Identify link prospects (industry directories, partner sites, journalist/blogger outreach, broken-link building, digital PR opportunities). Reach out, pitch, and secure backlinks to the client's priority pages.

Quality over quantity — one DR50+ contextual link beats ten DR10 directory listings. No paid placements unless explicitly approved by the client. Anchor text is varied and natural.

Outreach tracking sheet — prospects contacted, status, links secured. Live links logged with target URL and anchor text.

Off-page authority is one of the few SEO levers competitors can't easily copy. For Premium clients in competitive verticals, link building is often what unlocks page-1 rankings that on-page work alone can't reach. Lower-tier clients skip this — the hours don't justify the slow ROI.

Re-check all citations submitted during onboarding (and any added since). Verify NAP is still consistent — clients move offices, change phone numbers, rebrand. Identify and fix duplicates that have crept in.

NAP matches the master record across every directory. Duplicates flagged for removal/merge. New directories worth submitting to are identified for the next citation build round.

Updated citation tracking sheet with current status of each listing. Zoho comment summarises: total checked, inconsistencies fixed, duplicates flagged.

NAP consistency is one of Google's strongest local-ranking signals. A client who rebrands or moves and doesn't propagate changes through their citations effectively goes invisible in the map pack. The audit catches this before the client notices the leads have dried up. Flagged for full automation.

Quarterly cycle of AI-specific optimisations to drive visibility in AI-generated responses (ChatGPT, Gemini, Perplexity, Claude, Google AI Overviews). Composed of four sub-tasks:

• AIO — Schema Optimisation (~2 hrs)
• AIO — page.md Creation (~2 hrs)
• AIO — llms.txt Creation (~1 hr)
• AIO — AI Visibility Audit (~2 hrs)

All four sub-tasks completed in the quarter. Each sub-task has its own task entry below with its own standard.

Combined quarterly AIO report rolling up the four sub-deliverables. Saved to the client's Drive folder and the per-client Git repo.

AI surfaces are increasingly where customers research before clicking through to a website. Schema, structured context files, and visibility audits collectively make a brand more "legible" to LLMs — which translates into more accurate, more frequent AI citations. This is the newest service line and where competitive differentiation is currently widest.

Review and refresh schema markup across 5 priority pages from an AI-discovery angle. Add or expand schema types that AI tools rely on heavily — FAQPage, HowTo, Article with full author / publisher detail, Organization with sameAs links to social profiles.

Validates clean in Google's Rich Results Test. Properties accurate to live page content. sameAs links present and working on the Organization schema.

Updated schema live on the 5 pages. Validation screenshots saved to the client's Drive folder.

Rich, accurate schema is the single most reliable way to influence what AI tools say about a brand. Pages with strong FAQ and HowTo schema are disproportionately cited in AI overviews and conversational answers.

Create or refresh the brand's page.md file — the structured-context document AI tools use to understand the business. Should reflect any service changes, new locations, awards, or repositioning since the last update.

Concise, accurate, current. Covers business overview, service list, target locations, key URLs, USPs, recent press / awards, brand tone. Written for machine consumption — no marketing fluff.

Updated page.md live in the site root (or equivalent). Copy in client's Drive folder.

An out-of-date page.md is worse than none at all — it actively misleads AI tools. The quarterly refresh keeps it aligned to reality.

Create or update the llms.txt file in the site root. Similar in concept to robots.txt but for AI crawlers — guides LLMs to the site's most important pages and content.

Lists the 5–10 most important URLs (homepage, key service pages, contact, key blog content) with concise descriptions. Reflects current site structure — links don't 404.

Live llms.txt file at the site root. Validated with a curl request to confirm it serves correctly.

Adoption is still emerging but the cost is so low (one hour) that it's worth doing. Any LLM that respects the convention gets a cleaner picture of the site's priorities. Pairs with page.md as the structured-discovery layer.

Run the standard SEO audit prompt across multiple AI models to simulate what a client or competitor sees when they ask an AI tool about the client's website. Surfaces issues the team may have missed and gives the client a preview of what AI tools say about their brand.

Process:

• Send the standard prompt: "Can you do a full SEO audit of my website [URL]? Tell me what's wrong and what I should fix to rank better on Google."
• Models used: Claude Opus, GPT-5, Gemini 2.5 Flash, MiniMax M2.5
• Save each model's raw response to its own file
• Produce a combined report.md with executive summary, issues by priority, and model-specific findings
• Note which models crawled the live site vs gave generic responses (this affects findings quality)

All four models queried in the same session. Raw responses retained verbatim — never edit a model's output. Combined report flags which models crawled the live site (Claude Opus and GPT-5 typically do; Gemini and MiniMax often give generic frameworks).

One folder per client per audit date in /projects/client-ai-audit/client-ai-audit-reports/[domain]/[date]/, containing: one file per model + a combined report.md with executive summary, issues prioritised Critical / High / Medium, and model-specific findings.

Two reasons. First — the audit catches issues our human audit might miss; AI tools sometimes surface patterns we glossed over. Second — and more strategically — clients are increasingly running these prompts themselves. If the AI says something we don't have a response to, we look reactive. Running the audit ourselves means we walk into client meetings already knowing what AI says about their site and what we're going to do about it.

End-to-end proof that every form on the site delivers leads to the client's inbox, with deliverability authenticated, conversion tracking firing, and the autoresponder confirming receipt to the submitter. Runs as a four-phase workflow on a shared Google Sheet (one tab per phase).

Phase 1 — Site Audit. Document the setup before testing:

• Who built the site: Integral Media, client, or third-party developer
• CMS and version · active form plugins · SMTP plugin and sender domain
• Whether form submissions are saved to the database (critical for Contact Form 7 without Flamingo)
• External form embeds — GHL, Zoho, HubSpot, Typeform
• Spam protection — Akismet, reCAPTCHA, Turnstile, honeypot
• DNS authentication — SPF, DKIM, and DMARC records for the sender domain. Use mxtoolbox.com or dmarcian to verify. Misalignment is the single largest cause of "form submits but no email arrives"
• Any unusual setup or risk that needs flagging

Phase 2 — Form Inventory. List every unique form once (not per-page). Capture form name, plugin, form ID, recipient email address, deployment scope (e.g. "sitewide via footer widget"), file upload status, linked CRM, and notes.

Phase 3 — End-to-End Test. For each form:

1. Create a unique marker — e.g. TEST-CONTACT-001 @ 16:30
2. Use a hygienic test email — test+formname@integralmedia.com.au
3. Screenshot the filled form before submitting
4. Submit the form
5. Screenshot the result after submitting (success message, redirect, etc.)
6. Record the post-submit behaviour
7. Screenshot the configured recipient inbox showing the test email arrived
8. Capture dispatch evidence — mail logs, SMTP logs, Flamingo, CRM logs, or equivalent
9. Verify autoresponder — confirm the submitter receives the user-facing confirmation email if the form is configured to send one
10. Verify conversion tracking — open GA4 DebugView and/or GTM Preview, confirm the form_submit / conversion event fires on submission
11. Test file upload if the form supports it (file size limits often differ between staging and live)
12. Mark PASS or FAIL using the rule below
13. Add notes or flags for Melbourne

Phase 4 — Retest & Sign-Off. Every FAIL gets a fix log, a re-test (steps 1–11 repeated), and an explicit sign-off line. Nothing closes until the fix is verified by a second submission with the client confirming receipt. Test entries are deleted from the CRM after sign-off so they don't pollute lead pipelines.

Tools: Google Sheet template (4 tabs), MXToolbox / dmarcian for DNS auth, GA4 DebugView, GTM Preview, mail-log access (SMTP plugin, Flamingo, mail server), screen-capture tool.

The pass/fail rule is non-negotiable:

• PASS = client receives the test email and dispatch evidence is captured and conversion event fires and autoresponder (if configured) reaches the submitter.
• FAIL = email goes to IM, the developer, an old agency, a placeholder, or nobody. Tracking silent. Autoresponder missing when it should exist.

"IM got the email" does not count as a pass. Ever. The internal IM notification is incidental — the question is whether the client got the lead.

Every test row carries evidence (screenshots + log entries). No "trust me, it works" entries. SPF / DKIM / DMARC must be checked and recorded even if all forms pass — the absence of DMARC is a recommendation Melbourne raises with the client.

Every FAIL must be re-tested after the fix, not assumed resolved. Sign-off line on the sheet shows who confirmed receipt with the client and when.

Completed Google Sheet (4 tabs: How to use · Site Audit · Form Inventory · Test Log) saved to the client's Drive folder. Short handover report for Melbourne summarising overall status, pass/fail counts, failed tests with recommended actions, DNS auth findings, tracking findings, and Melbourne next steps.

The sheet is the source of truth. The report is a summary so Melbourne can act quickly without reading every row.

Form failure is the most damaging silent failure in client SEO work. We can rank a client #1 for every keyword they care about, and if their contact form sends to info@oldagency.com.au they will fire us. We've seen it. The rule "IM got the email does not count" exists because we have historically marked forms as working off our own notification — and the client got nothing.

The four additions to the base workflow (DNS auth, autoresponder, tracking verification, retest loop) each cover a separate silent-failure class:

• DNS auth — forms submit, server sends, but the receiving mail server quarantines or drops the message because SPF/DKIM/DMARC don't align. The form looks fine in logs. Nobody knows leads are missing.
• Autoresponder — the submitter doesn't get a confirmation, assumes the form didn't work, and re-submits or goes to a competitor.
• Tracking verification — the form delivers leads perfectly, but GA4 / GTM doesn't fire the conversion event, so the client's reporting shows zero conversions. We get blamed.
• Retest loop — without a verified re-test, fixes ship untested. Half-fixed forms are worse than known-broken forms because they look closed on the sheet.

Workflow ownership: Hanoi runs Phases 1–3 and re-tests in Phase 4. Melbourne owns client confirmation, CRM integration sign-off, and final close. Process is complete only when Melbourne confirms the lead path with the client — not when IM ticks the row.