How the Carcass Method Connects Website Design, Structure, and Data
The Carcass Method brings together four connected website layers: Surface, the visible website and the signals that build human trust; Structure, the experience beneath it, including interaction, navigation, and user flow; Data, the operational layer of business logic, systems, integrations, and core information; and The Carcass, the substrate under all three. Peppermint Global describes The Carcass as the machine-legible layer that connects the whole system and makes its meaning intelligible to AI, a deliberately engineered architectural layer grounded in design, linguistics, semiotics, and information structure. The framework is most useful when design, content, product, and engineering teams work together.
Surface: The Experience People Actually See
The Surface is the visible website: brand, visual design, interface, and the signals that build human trust, from layout and typography to product demonstrations and calls to action. It is not enough that a website simply looks good; the Surface should help the intended audience understand the offering and its value and lead them to the right place in the information architecture.
For a technical product, the experience should expose the value of complex workflows without losing the details. A feature card may describe the benefit in a sentence, while a deeper page explains the mechanics, supported integrations, and constraints. A diagram or animated description may illustrate an abstract process, but the essential meaning should not be locked inside an image or video.
A useful design test: can a first-time visitor identify the product, audience, use case, and next step without having to guess? If a person cannot tell, adding technical markup will not fix a page that is fundamentally unclear.
Structure: The Relationships Between Pages
Structure is the experience beneath the surface: interaction, navigation, wireframes, and the logic of user flow that help visitors find what they need and builds a coherent picture of the offering, including the relationships between a product page, feature page, integration directory, documentation, pricing, and supporting evidence.
With a coherent structure in place, a reader who discovers a particular value proposition should be able to find deeper explanations and supporting evidence for that claim. If a page promises to automate a certain kind of workflow, the internal links should show which workflow it is, how the automation works, and what has been proven about this particular process. Internal links also declare those relationships and help crawlers discover relevant pages.
Better structure does not mean more pages. A sprawling set of pages with repeated information or inconsistent terms across page types can cause confusion even at a small scale. With a focused set of pages, each with consistent and meaningful purpose, the relationships between them become clear.
Data: The Facts That Support the Experience
Data is the operational layer behind the website: business logic, systems, integrations, and core information, including the product facts shown on the pages (names, feature definitions, pricing, availability, integrations, technical requirements), the case-study details that demonstrate value, and the other supporting facts users look for. The key question is whether those facts are accurate, consistent across the site, and traceable to an authoritative source.
Contradictions across a homepage, pricing page, help center, and structured data can confuse visitors and make it harder for systems to interpret the offering consistently.
A useful practice is to have a source of truth for key facts, an owner, and a process for getting those facts into the website. Structured data should reflect the visible content and current documentation. Implemented correctly, it can support search features, but it never substitutes for accurate content. Google also says structured data must be accurate, and that valid markup may still not produce a rich result.
The Carcass: Connecting Meaning to Implementation
Peppermint Global describes The Carcass as the machine-legible layer that connects the whole system and makes its meaning intelligible to AI, a deliberately engineered architectural layer grounded in design, linguistics, semiotics, and information structure. It is not simply another name for schema markup or a file added after launch.
In practice, building this layer means clean HTML structure and crawlable links, consistent entity names and metadata, accurate structured data, and content that the relevant systems can actually access. It also requires checking that these things agree with one another: a product name on the interface does not contradict its name in the metadata, and a feature page does not declare capabilities that are not supported according to the source data.
Google’s published guidance for AI Overviews and AI Mode continues to focus on foundational SEO practices, crawlability, and useful content, and states that no special AI text files or schema markup are required to appear in them. The Carcass Method should be used to organize website work but should not promise a search outcome that no methodology can provide.
If the layers are considered independently, teams may optimize one while undermining another: a design team may hide text explaining some limitations in pursuit of a minimal layout, while a developer builds out a custom interaction that buries a vital detail. A content team may introduce a novel term to describe a product or its value without updating the supporting navigation or source data, and a technical SEO specialist may implement structured data that contradicts the page contents or claims to contain information that is not present.
The Carcass Method encourages collaboration by giving teams a shared vocabulary to understand the strengths and pitfalls of each stage of website building. In turn, that collaboration supports faster iterations and more thoughtful decisions about what to build, given limited time and resources.
An Example: Explaining a SaaS Integration
Imagine a SaaS company explaining how its product integrates with a customer relationship management platform. On the Surface, the page should say what the integration does and who it is for. Ideally, the user then knows what to do next: review instructions, or confirm that their use case is supported.
In Structure, the integration page must link to the relevant product feature, documentation, and known limitations, so visitors find what they need without wading through unrelated topics. Internal links should have clear labels and point to stable destinations.
In terms of Data, the integration’s name, capabilities, setup requirements, and availability should be drawn from a trusted source. If this integration is only available in certain plans or versions, this must also be accurately represented. Finally, at the Carcass layer, the page’s HTML, metadata, links, and any structured data should express the same integration details without contradicting the information found elsewhere.
A Cross-Functional Review Framework
The approach works best when each layer comes with questions that different teams can answer. Design can evaluate the page for accessibility and information hierarchy, while content can confirm that all claims are verifiable and use consistent language. Engineering can check the implementation: does the live code support what the page promises, and do any instructions or recommendations conflict? Product or operations leads can confirm that the underlying facts were correct when the page was published.
The table below summarizes each layer and a practical question teams can ask about it.
| Layer | Main responsibility | Practical review question |
|---|---|---|
| Surface | The visible website: brand, visual design, interface, and trust signals. | Can a first-time visitor describe the product and its target audience? |
| Structure | The experience beneath the surface: interaction, navigation, wireframes, and user flow. | Can a visitor get from the promised destination to the relevant feature, proof, or documentation? |
| Data | The operational layer: business logic, systems, integrations, and core information. | Do the web presence and its supporting documents tell the same story about the product? |
| The Carcass | The machine-legible substrate that makes the other three layers intelligible to AI. | Does the live implementation preserve clear concepts and relationships across the website? |
What the Framework Can and Cannot Do
The Carcass Method is a useful framework for collaboration and shared understanding, but it is not a shortcut. It helps teams see what it will take to make the website more coherent, consistent, and technically sound. Search systems decide independently what to crawl, index, and cite, based on many factors outside a website team’s control. The method cannot promise indexing, ranking, or citation, but it can make a website clearer, more consistent, and easier to interpret.
To explore how Peppermint Global applies this approach to website design, see its AEO-optimized website service.
FAQ
Is the Carcass Method the Same as Adding Schema Markup?
No. The Carcass Method is a framework for how the whole website communicates meaning. Peppermint Global describes The Carcass as the machine-legible layer that connects the whole system and makes its meaning intelligible to AI, a deliberately engineered architectural layer grounded in design, linguistics, semiotics, and information structure. Structured data may be one implementation element, but it is not the method itself.
Should a Website Be Designed for AI Instead of People?
No. The aim is to make the site clear and useful for people while ensuring its important information and relationships are also accessible to systems that crawl or interpret web content.
Does This Approach Guarantee AI Search Visibility?
No. The Carcass Method can help a team review how a website communicates, but it cannot guarantee visibility or citation. For Google AI Overviews and AI Mode, a page must be indexed and eligible to appear with a snippet to be eligible as a supporting link; Google still decides which eligible pages to show.
