Foundation

The Concrete the Other Four Layers Are Poured On

The spine of this book is three verbs. Understand. Trust. Recommend. Nothing happens until the first one is true. Before a machine can trust you or recommend you, it has to understand you, and to understand you it has to do two physical things. It has to reach your pages and render them. Then it has to read what it finds and resolve it to one coherent business. Foundation is both halves of that. Reachable and legible. The concrete the other four layers are poured on.

People split these into two jobs and treat them as separate disciplines. Technical SEO on one side, schema on the other. They are the same question asked twice. Can a machine get in, and once inside, can it tell what it is looking at. A site that loads fast and serves clean HTML but declares nothing about itself is reachable and illegible. A site with perfect schema buried behind a robots block or a client-side render is legible and unreachable. Both fail Foundation.

This is the fastest layer in the Stack and the most expensive one to skip. Authority takes years. Trust accrues at the speed of real customers. Foundation takes weeks. A business willing to commit a couple of engineer-days and one focused month can move from a Foundation fail to a Foundation pass on every diagnostic in this chapter. The catch is that the cost of skipping it is invisible. It does not show up in any dashboard. It shows up as the leads that never arrive because the proof was unreachable, and the recommendation that goes to a competitor because the machine could not resolve you to a single trustworthy entity.

What This Layer Solves

Here is the failure mode, and I will say it plainly because it is the one I see most. A business spends two years building something real. Reviews stack up. Original research ships. The founder gets quoted in trade publications. The site documentation is the deepest in the category. Then a buyer asks ChatGPT for the best option in the category and ChatGPT names a competitor. Not because the competitor has stronger proof. Because this business has Core Web Vitals in the red, a robots file that quietly blocks GPTBot, a sitemap that has not regenerated in eight months, a canonical setup that splits authority across four URL variants, and no schema declaring who it even is.

Let me make it concrete with my own site. While writing this chapter I ran the diagnostic against dogresources.com, which I own. Five distinct Foundation failures, three I did not know about. A misconfigured proxy that let Google see the same content at four URL variants and refuse to index any of them. Twenty-seven pages returning 404 from a content rebuild whose redirect plan had gaps. Forty-one pages Google saw, rated thin, and silently dropped. A robots file with no AI bot rules. A homepage with the bare minimum schema. The site lost 89 percent of its daily search impressions in nineteen days, traced to a Traefik redirect middleware that had silently fallen off a route during a routine migration.^[1] Five minutes of misconfiguration. Three weeks of compounding loss.

If I can carry five Foundation failures on a site I own, you almost certainly have at least one. That is not a knock on you. It is the natural state of any portfolio more than eighteen months old.

Now the half most generic SEO retainers get wrong. Ninety percent of standard technical SEO still applies. The other ten percent is the difference between ranking on Google and being reachable to answer engines, because answer-engine crawlers behave differently from Google's in four ways that change how this layer has to be built.

One. AI bots do not render JavaScript. Vercel analyzed roughly a billion requests across nextjs.org and partner domains in late 2024 and confirmed that none of the major AI crawlers execute JavaScript. ChatGPT's bot fetched content but skipped JS execution on 11.5 percent of its requests. Claude's bot did the same on 23.8 percent. Both hit 404 pages at more than 34 percent of requests, against Googlebot's 8.2 percent.^[2] In practice, a single-page React app that renders content client-side is invisible to ChatGPT and Claude. Googlebot will eventually render it after a delay.^[3] AI bots will not. Server-side rendering stopped being a performance preference. It is the price of admission.

Two. AI bots run under tighter resource constraints than Googlebot. Googlebot has years of accumulated patience. It retries, falls back, partially indexes. AI crawlers fetch on tighter cadences and skip pages that do not respond promptly. Independent log analysis across twelve production sites in early 2026 found GPTBot revisiting high-traffic pages every 2.4 days at roughly 4,200 daily hits, while ClaudeBot is slower and more selective with a 6.8-day cadence, and PerplexityBot has almost no scheduled background crawl, fetching pages only when a user query references the domain.^[4] A page Googlebot will eventually find may never be reached by an AI crawler.

Three. AI bots read robots directives more literally, and some ignore them entirely. Google publishes its crawler decisions in Search Console. When Googlebot is blocked, you find out. AI bots surface no equivalent diagnostic. If your robots file accidentally disallows them, or your CDN blocks their user-agent at the edge, you discover it months later when a buyer mentions a recommendation you did not get. It goes further. TollBit's Q1 2025 measurement found the share of AI crawler requests ignoring robots directives jumped from 3.3 to 12.9 percent in a single quarter.^[5] Cloudflare's August 2025 forensic report caught Perplexity using undeclared crawlers with rotating IPs to reach pages that explicitly blocked all automated access, and delisted it from the Verified Bots list in response.^[6] The signal you trust to control crawl is not always respected.

Four. AI bots weight canonical and entity signals differently, and training crawlers ignore canonical hints in the markup. A duplicate-content problem on a Google-indexed site fragments authority across versions. The same problem on an AI-indexed site can produce a canonical entity record that disagrees with the page the bot fetched, and the model resolves the disagreement by treating the entity as untrustworthy and discounting the recommendation. You did not get penalized. You got skipped. Cloudflare published data from its own developer documentation site in April 2026: across 4.8 million AI crawler hits over thirty days, training crawlers consumed deprecated content at the same rate as current content, and canonical tags, deprecation banners, and noindex meta tags made no measurable difference.^[7] The implication is that in 2026 canonical control happens at the edge, through redirects and server-side rules, not only in the markup.

Those four asymmetries are why reachability needs a deliberate deployment, not a generic checklist.

Reachability is half the job. The other half is legibility, where most sites are silently failing. Every AI system that answers questions about businesses runs the same process. It pulls candidate entities from training data, checks them against live web signals where it can, picks the most confidently identified and most corroborated entity that matches the query, and names it. Schema is how your site participates in that process. Without it, the system is guessing.

The guessing is specific. Text gives the model raw material. Schema gives it confirmed answers. That is the difference between being described and being declared. A homepage with the founder's name in the header, a list of services in the body, and a contact form at the bottom contains real, accurate information. Without schema, the model must infer that the name is a person, that the person owns the business, that the business sells services not products, that the contact details belong to this entity. It will get most of it right and not all of it right. Add Organization schema with a sameAs array, Person schema with worksFor, Service schema on the service pages, and the model has declarations instead of inferences. The record is anchored.

This matters more for AI systems than for the previous generation of search. Google's traditional ranking primarily used links and content to assess authority. AI citation systems use entity coherence. A business clearly and consistently declared as the same entity across its own pages and across third-party references is a business AI systems can recommend with confidence.

Google's own structured-data documentation states that schema helps its systems "understand the content of the page" and can make a business eligible for rich results including Knowledge Panels, featured snippets, and AI Overviews.^[8]

The second job legibility does is disambiguation. Common business names, personal names, and service categories all create it. "Rose Consulting" could be three dozen businesses. A url, a sameAs array, an address, a foundingDate collapse the ambiguity. The system knows which one.

And this is why legibility comes after reachability inside this one layer. A site with a broken canonical setup can have perfectly valid schema that still produces an inconsistent record, because the crawlers see the schema from multiple URL variants and cannot tell which declaration is authoritative. Fix the floor. Then declare the entity.

One reassurance before the diagnostic. The legibility half does not require a developer. Every schema type in this chapter is JSON-LD, a structured block of text in the page. No plugin, no database, no API. A non-technical practitioner can write and validate Organization schema in under an hour. The blocker is not technical. It is attention. Most business sites have never had anyone sit down and ask what exactly the business needs to declare about itself.

Two more traps worth naming, because they waste a lot of audit time. The diagnostic tool the industry leaned on for a decade, Google's public PageSpeed Insights API, was gated in 2026; the unauthenticated endpoint now returns a zero daily quota, so a Foundation audit needs an API key and a Google Cloud account.^[9]And Google's mobile-friendly test was deprecated in 2023, yet Search Console still surfaces a mobile_friendly field that returns a value which has not measured anything in three years.^[10] Most audit tools still call it. Do not grade a business on a metric that no longer exists.

The Diagnostic

Two passes. Reachability first, legibility second, same order as the layer itself. Run both before you write a word of proposal. The output is your Foundation scope.

Reachability (seven checks)

Check 1: PSI mobile score. Run the homepage, a key service page, and the top-traffic article through the PageSpeed Insights API (you need a key now, per the section above). Target 90 or better on mobile. Under 70 is a hard fail. The failing metrics matter more than the number. Largest Contentful Paint above 2.5 seconds and Cumulative Layout Shift above 0.1 are the two that correlate most with AI crawler abandonment in log analysis.^[4] Fix those two first.

Check 2: robots directives for AI bots. Fetch /robots.txt and check for explicit allow rules for GPTBot, ChatGPT-User, ClaudeBot, anthropic-ai, Claude-SearchBot, PerplexityBot, OAI-SearchBot, Google-Extended, and Applebot-Extended. A blanket User-agent: * allow covers most. The specific rules matter for crawlers that parse literally instead of inheriting the wildcard. Fail: any named bot in a disallow rule, or a Cloudflare Bot Fight Mode setting that blocks unrecognized crawlers by default.

Check 3: sitemap. Fetch /sitemap.xml. It should exist, return 200, reference your important pages, and contain no 404 URLs. Fail: missing sitemap, not submitted in Search Console, last modified more than 30 days ago on an active publishing site, or more than 5 percent 404 URLs. The staleness rule is sharper for AI bots, because PerplexityBot fetches only when a query references the domain and a stale sitemap gives it nothing to work with when it arrives.

Check 4: canonical host. Test these four variants and confirm they all resolve to the same final URL in one redirect: http://domain, https://domain, http://www.domain, https://www.domain. Fail: any variant that loads as a separate page or redirects through more than one hop. This is the failure that hit dogresources.com. Multiple live hostname variants split authority across identical pages, and AI bots fetching different versions build inconsistent entity records.

Check 5: HTTPS and SSL. Confirm the certificate is valid, not expiring inside 30 days, and covers every active subdomain. Check for mixed content. Fail: expired cert, mixed-content errors on the homepage or top pages, or a cert that does not cover www when www is canonical.

Check 6: Core Web Vitals in Search Console. Open the Core Web Vitals report. Any page in the Poor bucket is a Foundation fail for that page. The report lags real conditions by about 28 days, so read it as trend and pair it with PSI for current state.

Check 7: crawl errors and index coverage. Open Pages, then "Why pages aren't indexed." Note "Not found (404)," "Server error (5xx)," and "Crawled, currently not indexed." A few 404s are normal. More than 2 percent of indexed pages returning 404 is a fail. Large "Crawled, currently not indexed" counts usually point to thin content, duplication, or canonical confusion, which also drag on legibility.

Legibility (seven checks)

Check 8: Organization schema on the homepage. Load the source, search for application/ld+json, and confirm an "@type": "Organization" block (or a subtype: LocalBusiness, ProfessionalService, MedicalBusiness, LegalService). Fail: no JSON-LD, only WebSite schema, or Organization schema missing the sameAs array.

Check 9: Person schema for the founder or primary author. Search the homepage and About page for "@type": "Person". It needs name, url, jobTitle, worksFor linking back to the Organization, and at least two sameAs entries. Fail: no Person schema, or a Person not connected to the Organization.

Check 10: Service schema on service pages. On the top two service pages, search for "@type": "Service" with name, description, provider linking to the Organization, and areaServed for location businesses. Fail: no Service schema, or it appears on one page and not others.

Check 11: FAQPage schema where FAQs exist. On the top article and primary service page, check whether any visible FAQ section has "@type": "FAQPage" with Question and Answer blocks. Fail: a visible FAQ with no schema equivalent.

Check 12: BreadcrumbList on non-homepage pages. Open any post or service page and check for "@type": "BreadcrumbList". It should be on every page but the homepage. Fail: missing, or referencing URLs that do not match the canonical path.

Check 13: AggregateRating where reviews exist. If the business has Google, Trustpilot, or internal reviews, check the homepage or service pages for "@type": "AggregateRating" with a real ratingValue and reviewCount. Fail: a business with 50 or more reviews and no AggregateRating. One of the most commonly missed types.

Check 14: schema validation. Run every JSON-LD block through Google's Rich Results Test.^[11] A block with a validation error is effectively invisible to parsers. Warnings are acceptable. Errors are not.

The Core Moves

Ten moves, in order. Reachability before legibility. Each move unlocks the next.

Move 1: Fix the canonical host. Start here, not at PSI. Every HTTP variant should 301 to the HTTPS canonical, and you pick either the apex or www as canonical with the other 301ing to it. On a Docker and Hetzner setup this is a three-line Traefik middleware. On Cloudflare it is a page rule. On Apache or Nginx it is two redirect blocks. Test all four variants with curl before and after, and confirm each returns a single-hop 301. The dogresources.com fix took eight minutes. The recovery took three weeks, because Google had already assigned low-confidence canonical status to three of the four variants. Fix it early.

Move 2: Rewrite robots for the 2026 crawler set. A robots file that says nothing about AI crawlers is not neutral. It is an active ambiguity that some crawlers read as permission and others as a block. The minimum working configuration:

User-agent: *
Allow: /
Disallow: /api/
Disallow: /admin/

User-agent: GPTBot
Allow: /

User-agent: ChatGPT-User
Allow: /

User-agent: ClaudeBot
Allow: /

User-agent: anthropic-ai
Allow: /

User-agent: Claude-SearchBot
Allow: /

User-agent: PerplexityBot
Allow: /

User-agent: OAI-SearchBot
Allow: /

User-agent: Google-Extended
Allow: /

User-agent: Applebot-Extended
Allow: /

Sitemap: https://yourdomain.com/sitemap.xml

The explicit per-bot rules exist because some crawlers parse the wildcard block and stop reading. Redundancy is cheap. The one disallow worth adding is User-agent: Bytespider / Disallow: /; ByteDance's training crawler does not feed a product that serves your buyers.

Move 3: Regenerate and submit the sitemap. A sitemap is a live index, not a write-once document. A static one, or one that has not regenerated in more than 30 days, is lying to crawlers about the current state of your site. On Next.js a sitemap.tsthat pulls URLs from the database stays current on every request. On WordPress, Yoast or Rank Math regenerate on publish. On a custom PHP site, a daily cron outputs fresh XML. After regenerating, submit in Search Console and check the status 48 hours later. A parsing error there actively tells crawlers to distrust your site's state, so fix it first.

Move 4: Deploy server-side rendering for key pages. If your core pages render client-side, AI crawlers see a blank page; the Vercel study confirmed zero JS execution across all major AI crawlers.^[2] This is not necessarily a full migration. For WordPress or PHP, confirm key pages return content in the HTML response, not in JS that runs after load. Test by disabling JavaScript and reloading; if the content vanishes, the bots see nothing. For React SPAs, move the homepage, top service or product pages, and any candidate citation sources to server-side rendering. Webflow, Squarespace, and similar builders render server-side by default, so there this move is already handled.

Move 5: Fix 404s and thin-content pages. Pull the 404 list and reconcile every URL into one of three buckets: redirect it (ship the 301), restore it (the page should return content), or retire it (genuinely gone, no successor, remove it from the sitemap). Do not create redirect chains; each extra hop is another chance for an AI crawler to abandon the fetch. The "Crawled, currently not indexed" list is a different problem. Google reached those pages and judged them not worth indexing, usually thin content, near-duplicates, or no inbound internal links. Where any are supposed to be citation targets, they need content investment, not a technical fix. That work belongs to the Authority layer, but you flag it here.

With reachability fixed, the bot can get in. Now make what it finds legible.

Move 6: Declare the Organization. This is the entity anchor for the whole site. Every other block references back to it. Write it once, keep it on the homepage, reference it elsewhere by @id.

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://yourdomain.com/#organization",
  "name": "Your Business Name",
  "url": "https://yourdomain.com",
  "logo": {
    "@type": "ImageObject",
    "url": "https://yourdomain.com/logo.png"
  },
  "email": "hello@yourdomain.com",
  "telephone": "+1-555-000-0000",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "123 Main Street",
    "addressLocality": "City",
    "addressRegion": "Province",
    "postalCode": "A1A 1A1",
    "addressCountry": "CA"
  },
  "sameAs": [
    "https://www.linkedin.com/company/yourcompany",
    "https://twitter.com/yourhandle",
    "https://www.facebook.com/yourpage",
    "https://g.page/yourgbp"
  ]
}

The sameAsarray is the anchor's most important field. It tells every system which external profiles belong to this entity. A LinkedIn page pointing back to your site, and a site pointing to the LinkedIn page, creates a bidirectional signal; remove either end and it weakens. This is the field the Trust layer leans on later, so set it up clean now.

One honesty note on this field, because the industry argument in mid-2026 got loud enough that clients will quote it at you. In May 2026, Ahrefs tracked 1,885 pages that added JSON-LD and found no significant uplift in AI citations over the following thirty days.^[12]Half the industry read that as proof schema is dead. The study was clean and the conclusion was wrong, because it measured the one place schema was never doing the job: the moment a third-party assistant fetches a page at answer time, its extractor typically strips script blocks and reads the visible text. Google's own AI surfaces are the exception. Its structured-data engineer Ryan Levering confirmed in April 2026 that schema is "used as context served to models when doing fanouts."^[13]

Schema's route into the models themselves is longer and quieter, and it runs through this exact array. Training pipelines scrub JSON-LD out of the text models learn from; the corpus behind Google's T5 dropped any page containing a curly bracket, precisely to filter out code.^[14] What survives is the chain sameAs starts. Your schema anchors the entity to its canonical external records, those records feed the Knowledge Graph and the reference sources built on it, and those sources are weighted heavily in the corpora the next generation of models trains on. Suganthan Mohanadasan's three-lives breakdown is the cleanest published version of this argument: schema is entity infrastructure, not advertising.^[15]Registration raises the value of the thing registered, but it does it by making the claims verifiable, not by promoting them. You are not buying this week's citations. You are giving every downstream system, including ones that do not exist yet, a clean record to inherit.

Move 7: Declare the Person. Every business has a founder, owner, or primary author. That person is an entity. Declare them.

{
  "@context": "https://schema.org",
  "@type": "Person",
  "@id": "https://yourdomain.com/#founder",
  "name": "Full Name",
  "url": "https://yourdomain.com/about",
  "jobTitle": "Founder & CEO",
  "worksFor": {
    "@id": "https://yourdomain.com/#organization"
  },
  "sameAs": [
    "https://www.linkedin.com/in/yourprofile",
    "https://twitter.com/yourhandle"
  ]
}

The worksFor link to the Organization @id is the connective tissue between the person and the business. Without it they are two unconnected entities in the model. With it they are one coherent pair.

Move 8: Declare Services. One Service block per service page. The most important field after name is provider, which anchors the service to the Organization.

{
  "@context": "https://schema.org",
  "@type": "Service",
  "name": "AI Visibility Report",
  "description": "A five-layer visibility assessment covering reachability, schema, content architecture, corroboration, and AI discoverability. Delivered as a self-contained HTML report.",
  "provider": {
    "@id": "https://yourdomain.com/#organization"
  },
  "areaServed": {
    "@type": "Country",
    "name": "Canada"
  },
  "url": "https://yourdomain.com/visibility-report"
}

Move 9: Add the supporting types. Three more, low effort and high return. FAQPage is the most direct path into AI-generated summaries, because the Question and Answer format explicitly tells the model this is a question and this is its answer. Write real buyer questions, not marketing headlines.

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "What is AI Visibility and how is it different from SEO?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "SEO optimizes for search rankings. AI Visibility optimizes for recommendations. A business can rank on page one of Google and still be invisible to ChatGPT if it lacks the entity signals, schema, and corroboration that AI systems use to identify and recommend businesses by name."
      }
    }
  ]
}

BreadcrumbList goes on every non-homepage page; it is low effort and reinforces site architecture in machine-readable form. AggregateRating goes on the homepage or service pages where real reviews exist, using the verified ratingValue and reviewCount from Google Business Profile, Trustpilot, or your review system. Never estimate it. A fabricated AggregateRating is worse than none, because it will eventually conflict with the real review data AI systems read from third parties, and the conflict undermines the entity. Add WebSite schema on the homepage alongside Organization to declare the canonical URL.

Move 10: Validate, then verify. Run every block through the Rich Results Test before deploying. A single missing comma invalidates the entire block. After deployment, re-run the homepage, one service page, and one article, and check the Search Console Enhancements report after 48 hours to confirm the schema was processed.

The Walkthrough

One real engagement, both halves, compressed to the decisions that mattered. The site is an eight-year-old regional service business on WordPress, a mix of legacy and new content, no prior work on AI discoverability, no schema at all. The owner had noticed inquiry volume sliding over six months and could not explain it. Search Console was installed but never monitored.

Day 1: the audit. Canonical host: the site loaded at both http://domain and https://www.domain as independent pages, verified as separate Search Console properties, each accumulating some indexed URLs the other did not, neither accumulating enough of anything. robots: a default WordPress file blocking wp-admin and saying nothing about AI bots. Sitemap: last regenerated four months earlier, containing 23 URLs deleted during a content consolidation. PSI mobile: 44, with LCP at 4.1 seconds from an unoptimized hero image. 404 count: 31 internally linked URLs returning 404, three of them service pages linked from the homepage. Schema: zero of the seven types. Foundation score: a hard fail on both passes.

Days 2 to 4: the reachability fixes. Added an Nginx rule pushing all http and www variants to the canonical https apex in a single hop, tested all four with curl. Rewrote robots to the 2026 configuration from Move 2. Regenerated the sitemap via Yoast, removed the deleted URLs, resubmitted, confirmed clean at 48 hours. Of the 31 404s, 18 got 301s, 10 were removed from internal links, 3 service pages deleted in a plugin update were restored from backup. Resized the hero from 2.4MB to 180KB, added lazy loading, enabled CDN image optimization. PSI mobile moved from 44 to 81 in 48 hours, the climb to 91 waiting on a caching change in week two.

Days 5 to 6: the legibility build. With the floor stable, the schema could anchor to a single canonical host instead of fragmenting across variants. Organization on the homepage with a sameAs array of only active, verified profiles, leaving out two dormant accounts that would have weakened the signal. Person on the About page with worksFor linking to the Organization @id. One Service block per page, each description a plain two-sentence explanation, not marketing copy. FAQPage on the two pages with visible FAQ sections, rewriting one marketing line into a genuine buyer question first. BreadcrumbList swept across every non-homepage page through one template change. AggregateRating with the business's real Google numbers, and the WebSite block. Validated every block before deploying; one missing comma caught and fixed.

Day 30: first check. Canonical confusion resolving. The www property stopped accumulating new indexed URLs and impressions consolidated to the apex. Crawl errors dropped from 31 to 4. The Enhancements report showed Organization, BreadcrumbList, and FAQPage detections across the site.

Day 90: Foundation pass. PSI mobile 93. Canonical clean. robots verified against the named bot list. Sitemap regenerating on publish, no errors. 404 count 2, acceptable for an active site. Crawl coverage at 94 percent of submitted URLs, up from 71. All seven schema types valid across the audited pages. The owner had not changed the content, the offer, or the design. Foundation was the entire intervention, and organic inquiry volume began recovering in week six, consistent with the three to six week lag between a crawl change and a ranking change.

A Foundation pass does not produce a citation. It produces a site AI crawlers can reach and read. The citation comes from the layers above.

Common Mistakes

Mistake 1: blocking AI bots in the security config, not just robots. robots is advisory. Cloudflare Bot Fight Mode, WAF rules, and rate limits are not. A business that enables a "block AI scrapers" setting blocks every named AI crawler at the edge before they ever read the robots allow rules you carefully wrote. After updating robots, test each named bot user-agent against your security settings. Many hosts set these aggressively during setup and forget them.

Mistake 2: treating www and apex as equivalent. They are not equivalent until you make them equivalent. A site serving content at both has two entity records in the crawlers' models, one the business and one noise, and the crawlers decide which is which on signals you may not control. The fix is one redirect. Recovery from fragmented records takes months.

Mistake 3: submitting the sitemap once. Search Console stores the submission record; it does not guarantee the sitemap stays current. If generation breaks or starts emitting errors, the last submitted version still shows as valid. Check the status once a month. Thirty seconds.

Mistake 4: optimizing for Lighthouse, not PSI. Same scoring model, different inputs. Lighthouse runs against your local browser and network; PSI runs from Google's infrastructure against production. A site that scores 95 in Lighthouse and 48 in PSI is common. Report and optimize against PSI.

Mistake 5: schema that contradicts the on-page copy. The most damaging legibility mistake. Organization schema that says "Rose Financial Consulting Ltd." while the heading reads "Rose Financial" forces the model to resolve a contradiction, and it does so by downgrading confidence. The schema name must match the on-page name exactly. If the page says "serving clients across Canada" and the schema says areaServed: "Ontario", that is a contradiction too.

Mistake 6: sameAs linking to inactive or wrong profiles. A sameAs array with six profiles, two dormant and one belonging to a different business with a similar name, does more damage than two verified active ones. AI systems cross-reference these links against the data at those URLs. A sparse, inactive profile adds noise instead of corroboration. Audit every link before adding it: active, clearly the entity, linking back to the canonical URL.

Mistake 7: schema on the homepage and nowhere else. The homepage Organization block declares the entity. The Service, FAQ, and BreadcrumbList blocks on interior pages confirm and extend it. Schema only on the homepage is a business card with a name and no description: the entity is declared and the services are invisible. The same goes for FAQPage written as marketing ("Why choose us?") rather than as the questions buyers actually ask, which AI systems do not extract.

Mistake 8: assuming Foundation is a one-time task. Every migration, CDN change, new plugin, and hosting move is a potential regression. A clean canonical host can break in a platform upgrade, a sitemap can stop regenerating after a CMS update, a robots file can revert to a default during a plugin conflict, a schema plugin can silently stop emitting Service blocks. Foundation maintenance is a 30-minute monthly review, not a deployment. And do not let a schema plugin stand in for the work: plugins generate basic Organization and WebSite schema, but not Service, not Person with worksFor, not FAQPage per article. They handle roughly three of the seven types. Running a plugin and marking the layer complete is the most common way this work gets sold short.

Case Study: Unreachable and Illegible to Reachable and Legible

The client: a veterinary urgent care clinic in a mid-sized Canadian city. Three veterinarians. A Google Business Profile with strong reviews and a 4.7 average. A website built four years earlier by a local agency and not touched since. A steady stream of clients from word of mouth, and a new competitor, opened eighteen months prior, showing up first in Google Maps and in AI search responses for emergency vet queries in the area.

The owner's question when we started: is it our website or our reviews?

Neither, on its own. It was Foundation, both halves. The clinic was unreachable to half the crawlers checking it and illegible to all of them, while a competitor with a clean floor was being read clearly and recommended.

What the diagnostic found. On reachability: content served at both the apex and the www subdomain as independent pages, the www version set as default by the agency and verified in Search Console, splitting impressions across two properties the owner did not know existed. robots blocked wp-admin and said nothing about AI bots. The sitemap was the original from the build, referencing three pages deleted eighteen months prior. PSI mobile sat at 51, dragged down by three images over 1MB above the fold and a render-blocking fonts request. Fourteen URLs returned 404, six still linked in the homepage navigation. And the quiet killer: GPTBot was being blocked by Cloudflare's default bot protection, configured during the build, returning a 403 at the edge on every request, so the robots file was never even read.

On legibility: zero of the seven schema types. No JSON-LD anywhere. The About page named the founder in a heading and a bio but declared no Person. The service pages had detailed descriptions and no Service schema. The site was, to a machine, an unlabeled set of pages it could only half reach.

The competitor showing up in the AI responses had a clean canonical host, a current sitemap, an open robots file, and at minimum Organization, Person, and Service schema on its core pages. Its advantage was not a better practice or a deeper review profile. It was a floor that let the machines reach and read it.

The intervention. Reachability first, the same ten moves in order. The single most important fix was finding and disabling the Cloudflare GPTBot block, because no robots rule and no schema matters on a page the crawler is handed a 403 for. Then the canonical 301, the 2026 robots file, a regenerated sitemap, the hero images compressed and fonts self-hosted (PSI mobile 51 to 88 in 72 hours), three deleted service pages restored and the rest 301'd. Then legibility: Organization, Person for the lead veterinarian, one Service block per page, FAQPage, AggregateRating with the clinic's verified Google numbers, BreadcrumbList sitewide, WebSite. Every block validated before deploying.

Total time: a little over two working days. No content written. No design changed. No new pages built.

The result. By day 30, impressions were consolidating to the canonical apex, GPTBot crawl activity was visible in the server logs for the first time, and the Enhancements report showed Organization, FAQPage, and BreadcrumbList detections. By day 60, PSI mobile was stable at 91, the canonical clean, the sitemap error-free, and crawls were confirmed across GPTBot, ClaudeBot, and PerplexityBot in the logs. The Google Maps ranking for the core emergency vet query moved up, and one Perplexity response that had previously named only the competitor now listed both clinics.

The owner's original question was the wrong question. The reviews were always strong. The website had been invisible to half the crawlers checking it and unreadable to all of them. The competitor had not done anything extraordinary; it had a clean technical floor and a few schema blocks, and that alone was the advantage. Once the floor matched and the entity was declared, the stronger underlying business started to show.

That is the Foundation argument in one case. The work is not glamorous and the results are not dramatic in the first week. But no other layer in the Stack can function if this one is broken.

Build the floor first. Everything above it depends on it.

Frequently Asked Questions

Sources

1. Original research, Lesli Rose, May 2026. Google Search Console Coverage report for dogresources.com, exported May 9, 2026. Daily search impressions: 444 (April 14, 2026), 84 (April 30, 2026), 49 (May 3, 2026). Root cause: a Traefik HTTPS-redirect middleware missing on three of four hostname variants. Source data archived.
2. Giacomo Zecchini, Alice Alexandra Moore, Malte Ubl, and Ryan Siddle, The Rise of the AI Crawler, Vercel, December 17, 2024. Monitoring of nextjs.org and the Vercel network over several months: "None of the major AI crawlers currently render JavaScript."
3. Ziemek Bućko, Google Needs 9x More Time to Crawl JS than HTML, Onely, November 9, 2022. Matched-pair controlled experiment: 313 hours for JS pages versus 36 hours for equivalent HTML pages.
4. Digital Applied, Agentic Crawler Behavior: 30-Day Site Log Study, April 26, 2026. Sample: 12 production sites with reverse-DNS verification on major bots.
5. PPC Land coverage of TollBit's Q1 2025 State of the Bots report, Blocking AI Crawlers Cost News Publishers 7% of Traffic, Study Finds, 2025. The 3.3% to 12.9% robots non-compliance change is corroborated by Cloudflare and Business Insider reporting.
6. Gabriel Corral, Vaibhav Singhal, Brian Mitchell, and Reid Tatoris, Perplexity is Using Stealth, Undeclared Crawlers to Evade Website No-Crawl Directives, Cloudflare, August 4, 2025. Reproducible test with brand-new test domains and explicit robots blocks.
7. Cam Whiteside, David Belson, and André Cruz, Redirects for AI Training: Honoring Canonicals at the Edge, Cloudflare, April 17, 2026. Sample: 4.8 million AI training crawler hits to developers.cloudflare.com over thirty days. "The advisory signals made no measurable difference."
8. Google Search Central, Introduction to Structured Data Markup in Google Search. Recommended format: JSON-LD. Accessed June 2026.
9. Confirmed empirically May 9, 2026: the unauthenticated PageSpeed Insights API returns HTTP 429 with a zero daily quota without an API key. Free-tier API keys are available via console.cloud.google.com with a 25,000-call daily quota.
10. Google Search Central, Mobile-Friendly Test API and tool deprecation, announced November 2023, removed December 1, 2023. The Search Console URL Inspection API mobile_friendly field continues to return values that no longer reflect a current measurement.
11. Google, Rich Results Test. First-party validation tool for JSON-LD, Microdata, and RDFa, with line-level error diagnostics. No account required.
12. Louise Linehan and Xibeijia Guan, We Tracked 1,885 Pages Adding Schema. AI Citations Barely Moved., Ahrefs Blog, May 11, 2026. Causal design: 1,885 pages that added JSON-LD versus roughly 4,000 matched controls, 30-day windows. Google AI Mode +2.4% and ChatGPT +2.2% (indistinguishable from zero), Google AI Overviews -4.6%. The study's own limitations note it did not test index-pipeline or training-time effects.
13. Schema App, Google Search Central Live Toronto: What Actually Matters in AI Search, April 2026 recap. Google structured data engineer Ryan Levering, on the record: "Schema is used as context served to models when doing fanouts."
14. Colin Raffel et al., Exploring the Limits of Transfer Learning with a Unified Text-to-Text Transformer, arXiv 1910.10683, 2020. The C4 corpus cleaning removed any page containing a curly bracket to filter out code. Corroborated by Jesse Dodge et al., Documenting Large Webtext Corpora, arXiv 2104.08758, 2021.
15. Suganthan Mohanadasan, The Three Lives of Schema Markup, suganthan.com, May 13, 2026, updated May 28, 2026. Practitioner analysis separating schema's three consumers; its load-bearing claims are independently sourced in sources 12 through 14.