For about twenty years, schema markup did one thing. It answered a question.

What is this page about?

You marked up a product so Google could show the price. You marked up an article so it could show the author and the date. You marked up your business so the hours showed up in the little box on the right. That was the whole game. Schema was a description layer. You told the machine what was already sitting on your page, and the machine displayed it a little better.

That era is ending. Not because describing things stopped mattering. It still matters. But a second question is showing up right behind the first one, and it changes everything.

What can a machine actually do here?

The agent doesn't browse your site. It uses it.

Think about how a homeowner books a service call today. They land on a contractor's site. They scan for a button that says "Schedule" or "Book Now." They pick a service. They squint at a calendar. They pick a slot. They fill out a form. They hit confirm. Every single step is a human looking at a screen that was built for human eyes.

Now picture an AI agent doing the same job for that homeowner.

The agent doesn't want your hero image. It doesn't care about your nav menu or your carousel of five-star reviews. It wants three things, and only three things:

1. What services do you offer?
2. When are you available?
3. How do I lock one in?

If that agent has to crawl your page and guess which button is the real submit button, the whole thing is held together with tape. It breaks the moment you redesign your site. It breaks if you move a form field. It breaks if a plugin updates.

So the web is starting to do something smarter. Instead of making agents guess, sites are starting to just tell them. Here is what you can do. Here is exactly how to do it.

That's the leap. Your website stops being a place to look at and becomes a set of things you can do. Your sitemap of pages picks up a shadow. A sitemap of actions.

The funny part: this vocabulary has been sitting there for years

Here's what I love about this. The tools for it already exist. They've existed for a long time. Almost nobody used them.

Schema.org, the same vocabulary you've been using to get rich snippets, baked in something called Actions years ago. ReserveAction. BuyAction. ScheduleAction. OrderAction. These were built to describe not what a thing is, but what you can do to it.

And they basically sat in a drawer. Unused. Because there was no reason to use them. A search engine showing a blue link had no need to know your booking endpoint. Why would it? It just needed to show the link and let the human do the rest.

Now the human isn't doing the rest. The agent is. And suddenly that dusty old vocabulary is the most important thing on your site.

Here's what it actually looks like. Say you're an HVAC contractor and you offer a furnace tune-up. Today your schema probably looks something like this:

{
  "@context": "https://schema.org",
  "@type": "Service",
  "name": "Furnace Tune-Up",
  "provider": {
    "@type": "HVACBusiness",
    "name": "Green Mountain Heating & Air"
  },
  "areaServed": "Burlington, VT"
}

That's fine. That's a description. It tells a machine this page is about a furnace tune-up offered by a company in Burlington. A search engine can read that and show it. Good.

Now here's the same thing, but built for an agent that needs to actually do something:

{
  "@context": "https://schema.org",
  "@type": "Service",
  "name": "Furnace Tune-Up",
  "provider": {
    "@type": "HVACBusiness",
    "name": "Green Mountain Heating & Air"
  },
  "areaServed": "Burlington, VT",
  "offers": {
    "@type": "Offer",
    "price": "149.00",
    "priceCurrency": "USD"
  },
  "potentialAction": {
    "@type": "ScheduleAction",
    "target": {
      "@type": "EntryPoint",
      "urlTemplate": "https://greenmountainhvac.com/book?service=furnace-tuneup",
      "actionPlatform": "https://schema.org/DigitalPlatform"
    },
    "result": {
      "@type": "Reservation"
    }
  }
}

Read that second one carefully. It's not saying "this page is about a furnace tune-up." It's saying "this thing is bookable, it costs $149, here is exactly where the booking happens, and here is what you get back when you do it."

That's not a label anymore. That's a lever. The agent can pull it.

And notice what just happened to your pricing

Look at that block again. There's a number in it. $149.

For twenty years that price tag, if you even put one in your markup, was decoration. A nice-to-have. Maybe it showed up under your search result and made the listing look a little more complete. It was a string of text a human glanced at and then ignored or didn't.

That's over too. In the agentic web, the price isn't decoration. It's an input. The agent reads it, compares it, and decides on it. Your Offer and your price and your priceCurrency aren't there to look nice in a snippet anymore. They're the numbers a machine uses to make a buying decision on a real person's behalf.

Sit with what that means. When a homeowner tells their agent "find me a furnace tune-up under $200 this week," the agent isn't reading your headline. It's reading your Offer. If your price is wrong, stale, or missing, you don't show up in that comparison. Not because you ranked badly. Because you never gave the machine a number to work with. You weren't even in the room.

This is the part a lot of people are going to get burned on. Plenty of contractors keep their real pricing vague on purpose. "Call for a quote." That worked fine when a human was on the other end, because a human would call. An agent won't call. An agent that hits a wall where the price should be just moves on to the contractor who put a real number there.

I'm not saying publish every price for every job. Some work genuinely needs a site visit before anyone can quote it honestly, and pretending otherwise is its own kind of BS. But for the stuff that has a real, knowable price, a tune-up, a service call fee, a standard install, that number needs to be in your structured data, accurate, and current. Treat it like the working part of the machine it's about to become. Because a wrong price an agent acts on isn't a typo anymore. It's a transaction.

A whole new stack is getting built on top of this right now

If it were just the old schema vocabulary waking up, that'd be interesting enough. But in 2026 there's a whole layer of new standards getting built to make these actions executable, not just declarable.

I'm not going to pretend I have a crystal ball on which one wins. Nobody does yet. That uncertainty is part of the story. But here's the short version of what's in play:

WebMCP, proposed by Google and Microsoft and now being worked on at the W3C, lets a website register actual tools an agent can call. "Check availability." "Add to cart." "Start a booking." The agent calls the tool directly instead of reverse-engineering your buttons.

NLWeb, from Microsoft, turns your site into something an agent can just ask questions of through a standard endpoint. The thing I find telling: it's built on top of existing schema and feeds. By the same guy who shaped Schema.org and RSS in the first place. He's not throwing out the old work. He's building on it.

Commerce protocols from Google and Shopify and OpenAI are turning checkout itself from a page you look at into a protocol a machine can run, with the payment piece handled by its own emerging standards.

Different approaches. No clear winner yet. But every single one of them assumes the same thing underneath. Clean, accurate, structured data.

And that's the whole point I keep coming back to.

This is the fundamentals argument all over again

I've said this for years and I'll say it again here because it's never been more true. The flashy stuff on top changes every couple of years. The fundamentals don't.

All these new protocols, the ones getting all the attention right now, are sitting on top of structured data. If your site is modeled well, if your entities are clean and accurate and actually reflect your business, you're most of the way ready. You barely have to do anything.

If you treated schema as a rich-snippet trick, something you bolted on to game your way into a better-looking search result, you've got nothing for an agent to stand on. The house of cards doesn't fall down dramatically. It's worse than that. It just quietly does nothing while your competitor's site gets used.

This is the same thing I say about every shortcut in this industry. Fake reviews. Private blog networks. Inflated metrics. Anything built to fool an algorithm instead of serve a customer. It works right up until it doesn't, and when it stops working it costs you more than it ever paid. The agentic web is just the newest version of the same lesson. The boring, real work is what holds up. Everything else is borrowed time.

The hard part isn't the markup. It's understanding your own business.

Here's where this gets real for contractors and for anybody running an actual business instead of a marketing demo.

The markup is the easy part. Copying that JSON block up there is the easy part. Anybody can do that.

The hard part is mapping what your customer actually does. Walk through it. A homeowner's furnace dies in January. What are the real steps? They need to find you. They need to know you handle emergencies. They need to book. Maybe they need to reschedule. They need a quote. They need to know when the tech is coming.

Every one of those steps is a real-world action. And every one of them has to be made legible to a machine that has no eyes and no common sense. It can't infer. It can't squint at your page and figure it out like a person would. You have to tell it, cleanly and explicitly, exactly what it can do and how.

That's not keyword work. That's not even really SEO in the old sense. That's understanding how your business actually runs, step by step, and being able to describe it to a machine. Which, if I'm honest, is the whole job and always has been. The markup just makes you prove you actually understand the process.

What this means for you, plainly

For most of the time I've been doing this, the goal was visibility. Be found. Be ranked. Be shown. Get cited.

That still matters. But there's a second thing now, and it's a different axis entirely. Call it actionability. Can an agent actually use you?

Because here's the uncomfortable truth. A page can rank perfectly, look beautiful, and load fast, and still be a complete dead end to an agent. Because it never said what you can do with it. In the old web, a great-looking inert page was still useful, a human could figure it out. In the agentic web, an inert page is just a wall.

The contractors and businesses that win the next decade won't be the ones with the most pages an agent can read. They'll be the ones with the most actions an agent can complete.

Book the appointment. Get the quote. Reschedule the visit. Buy the part. Each one of those, exposed cleanly, as a thing a machine can actually do.

So here's my advice, and it's the same advice I'd give about anything.

Don't chase the protocol wars. Don't wait for a winner to be declared. Get your fundamentals right. Model your business honestly in your structured data. Map the real actions a customer takes and make every one of them clean and explicit. Do that, and whichever standard wins, you're ready.

Keep it simple. Make it work. And build it on something real.

The vocabulary's been waiting in the drawer for years. The agents finally showed up to use it. The only question is whether your site has anything for them to do.

For two years now, the marketing industry has been pitching contractors a new acronym every six months.

AEO. GEO. AI Optimization. LLMS files. Special schema. Content chunking. AI-friendly rewrites.

A new shortcut. A new service tier. A new invoice line item.

This week, Google published an official guide called Optimizing your website for generative AI features on Google Search. It went live on May 15, 2026, on the Search Central blog.

I will save you the click. Here it is, in their own words:

“Is SEO still relevant for generative AI search? In short, yes!”

That is not a tease. The rest of the guide spends most of its time telling site owners that the things being sold to them as “AI SEO” do not actually do anything. Same playbook. Same fundamentals. Same work.

What Google says you can ignore

The guide has a section called “Mythbusting generative AI search.” These are the tactics Google is officially telling you to skip:

• llms.txt files and other “special” markup. You do not need AI text files, machine readable files, or any special markup to appear in AI features. Google may crawl those files. That does not mean it treats them as special.
• Chunking your content. No need to break pages into tiny pieces for AI to understand them. Google’s systems handle nuance across multiple topics on one page.
• Rewriting content just for AI. AI understands synonyms. You do not have to capture every long-tail variation or write in some special “AI-friendly” way.
• Seeking inauthentic mentions. Buying blog mentions, fake reviews, paid forum posts, and any other manufactured “AI citation” play. Google says quality is what gets cited and that spam systems block the rest.
• Over-doing structured data. There is no special schema just for AI Overviews. Existing structured data is still useful for rich results. That is it.

If your marketing vendor has pitched any of these as the new must-have for AI search, you now have Google’s own public documentation saying it does not matter.

What still works

Same things that worked last year. Same things that worked five years ago.

• Unique, non-commodity content. Google’s example, almost word for word, is the difference between “7 Tips for First-Time Homebuyers” and “Why We Waived the Inspection & Saved Money.” One is recycled common knowledge. The other is real, lived, expert-led experience. For contractors, this is your home turf. The install nobody else would touch. The repair that turned out to be three problems stacked. The truck-roll that saved a homeowner ten grand. That is the content that earns visibility in AI search.
• Clear technical structure. Pages have to be crawlable, indexable, and eligible to appear in Search. Site has to work on mobile. It has to load. The main content has to be easy to find.
• Good page experience. Easy to read. Easy to use. Not buried under junk.
• Real local and business signals. Google Business Profile. Merchant Center. Accurate, consistent business details. The unglamorous infrastructure that has always mattered.

That is the whole list.

Why this matters for contractors

Here is the part I care about most.

Contractors have been getting pitched “AI optimization packages” for over a year now. Some of those pitches come with five-figure monthly fees. Most of them are either repackaging things that were already part of basic SEO, or selling tactics that Google is now publicly saying do not work.

If a vendor is asking you to pay extra for:

• An llms.txt file on your site
• “AI-ready content rewrites”
• A “GEO audit”
• “AI citation building”
• Special schema markup just for AI Overviews

Ask hard questions. Google’s official position, in a public document updated this week, is that none of that is required to show up in AI Overviews or AI Mode.

What is required is the work. Useful content from people who actually do the job. A site that loads. A real business with real signals.

The takeaway

Nothing changed.

The interface changed. AI Overviews show up. AI Mode exists. Citations are surfaced differently. The way clicks come in is shifting, and the traffic data is real.

But the work that earns visibility? Same work as always.

Earn it with content real people actually want. Build it on a site that works. Run a business that deserves to be recommended.

That is what we have been telling our contractor clients since AI Overviews launched two years ago. Now it is in Google’s own documentation.

Keep it simple. Make it look beautiful. Have it work.

The shortcuts never worked. They just took longer to fail.

Last month Google Labs open sourced the format that powers their Stitch tool. It is called DESIGN.md. A single Markdown file. YAML at the top with your design tokens. Prose underneath explaining the why. Drop it in your project root and your AI coding agent reads it before it writes a line of UI.

If that pattern sounds familiar, it should.

CLAUDE.md does the same thing for code. AGENTS.md does it for general agent behavior. README.md has done it for humans reading your repo for thirty years. Now DESIGN.md does it for visual identity.

You are going to see a lot more of these. Buckle up.

The Pattern

The shape is always the same. Plain text file. Lives in your project root. Versioned in Git. Readable by a human. Parseable by a machine. No platform, no plugin, no lock in.

You can already see where this is headed. SECURITY.md for your security posture. DATA.md for your schema and naming conventions. BRAND.md, TONE.md, VOICE.md for marketing. Whatever the next agent needs to know about your business, somebody is going to write it down in a Markdown file and check it into the repo.

This is good. This is how it should work.

Autonomous Does Not Mean Omniscient

Here is the part people keep missing about AI agents.

Autonomous and smart are not the same thing. An agent can run on its own. That does not mean it knows what you want. It does not know your brand. It does not know your tolerances. It does not know that your contractor client's customers are mostly homeowners over fifty who will not tap a button smaller than their thumb. It does not know that your manufacturer partner has spent twenty years building a quiet, engineered brand and would rather die than ship a screen with a gradient on it.

It cannot know any of that. Not until you tell it.

Most of the complaints I hear about AI output come back to the same thing. The agent did exactly what it was asked to do. It just was not asked the right way. It did not have the context. So it guessed. And the guess looked generic, because the average of everything on the internet is generic.

The fix is not a better model. The fix is better inputs.

Constraints, Guardrails, Variables

That is what these Markdown files actually are. Constraints. Guardrails. Variables. The three things every good engineer and every good designer has always used to make sure the output is not a coin flip.

A DESIGN.md file says: these are your colors, these are your type sizes, this is the why behind them, here is what you do not do. That is a guardrail. It does not slow the agent down. It points it in the right direction so the work it produces is actually useful.

CLAUDE.md does the same thing for code. Here are the conventions we use. Here is the framework we have picked. Here is what we do not want, even if you have seen other people do it. Same pattern. Same purpose.

This is not gatekeeping the AI. This is operating it the way it was meant to be operated.

Now Think About Your Own Business

Here is where I want you to stop reading for a second.

Think about your business. Your craft. The thing you do every day that you are good at. Now ask yourself: what are the rules of how it works that you have never written down?

Every business has them. They live in the head of the founder. They get repeated in the meeting the new hire missed. They show up the moment somebody does it wrong and gets corrected. Tribal knowledge. Unwritten. The stuff "we just kind of know."

That is your DESIGN.md. That is your CLAUDE.md. That is your AGENTS.md. You just have not written it yet.

If you run an HVAC shop, your rules might be: we run service calls in these zip codes and not those. We do not sell on price. We answer the phone in two rings during business hours and within fifteen minutes after hours. We do not install equipment we cannot service ourselves. Our techs wear shoe covers, every time, no exceptions. Those are guardrails. They are why your customers trust you. Right now they live in your head.

If you run a manufacturing brand, your rules are the ones your dealers are quietly bending in ten directions right now. Logos in the wrong colors. Co-op ads that look nothing like your brand. Product photos shot in somebody's garage under fluorescent lights. You have a PDF brand book somewhere. Nobody reads it because nobody can search it, version it, or hand it to an agent.

If you run an agency, your rules are the ones the new project manager learns the hard way. What clients you take. What you charge. What stack you build on. What you say no to. What "done" actually means.

None of that is in a Markdown file yet. It probably should be.

My Version of This

At Red Barn we have been doing this in pieces for years. Our tech stack is documented. Our design system is documented. The way we build SEO for a contractor is documented, because we have done it hundreds of times and the process is the process.

Now we are writing it for the agents. Same content, slightly different format. Tokens at the top. Prose underneath. The why next to the what. So when an AI helps us build a contractor's site, it does not start from the average of the internet. It starts from how we do it. Our colors. Our defaults. Our patterns. Our reasons.

That is the work. Not picking the model. Not chasing the new tool. Sitting down and writing down what we actually do, in a format that a human and a machine can both read.

Most businesses I see have not done this. The rules live in the founder's head and in the team's habits. It runs fine that way until you want to scale, or hire, or hand off, or use any tool that needs to be told what good looks like. Then the absence of written rules is the bottleneck.

AI is exposing this. AI is not the only reason to write your business down. It is just the loudest one.

What This Means If You Pay for Software

If you are a contractor, a manufacturer, or anybody buying digital work from an agency, here is the part to take with you.

The companies that get good output from AI are not the ones with the fanciest model. They are the ones with the best inputs. The clearest brand. The cleanest standards. The most explicit guardrails. If your vendor cannot tell you where their constraints live, where your tokens are defined, where the rules for your project are written down, your output is going to be generic no matter how powerful the model is.

Ask where the Markdown lives. Ask to see it. If the answer is "we just kind of know," you are paying for guesswork.

Where I Land

DESIGN.md is not a moment. It is a marker on a trend that started with README and is going to keep going. The shape of the future is small text files that tell agents what you actually want.

Autonomy without context is just expensive guessing. Constraints are not the enemy of speed. They are the reason speed is worth anything.

Write your business down. Version it. Hand it to the machine.

Simple. Beautiful. Works.

---

Open source is just where you can see it.

Two stories broke on the same day. Google said it caught hackers using AI to find and exploit a previously unknown vulnerability for the first time. That same day, an attacker pushed 84 malicious versions across 42 npm packages in the TanStack project. Twelve million people install one of those packages every single week.

That timing isn't a coincidence. It's the new normal.

I've been building on open source since the early days of the web. My first websites were hand-coded HTML stitched together with libraries I pulled off random forums. Almost everything we build at Red Barn sits on top of open source. PHP,Apache, Linux, Node packages. Without open source, the internet looks completely different. Smaller. Slower. More expensive. Less innovative.

I don't want anyone walking away from this post thinking open source is the problem. It isn't.

Here's the part I want to make clear up front. Open source is where you see these stories. The code is public. The build pipelines are public. The post-mortems are public. That visibility is a feature.

Closed-source software has the same supply chain. It just runs out of view. When a vendor's build system gets compromised, you might never hear about it. SolarWinds is the cautionary tale everyone remembers. There are plenty of others you've never heard of.

So when I talk about open source attacks in this post, I'm using them as the visible example. The lesson applies to every piece of software your business runs on. Free or paid. Open or closed. SaaS, on-prem, the stuff your team logs into every morning. All of it.

The pattern

Look at what's been happening.

A self-replicating worm called Shai-Hulud tore through npm, hitting packages with over 2.6 billion weekly downloads combined.

Then the Axios HTTP library got compromised. 70 million weekly downloads. Attributed to a North Korean state actor.

Then Bitwarden's CLI tool got hit. So did Aqua Security's Trivy scanner. So did core SAP developer packages.

Then TanStack. 84 malicious versions across 42 packages, with over twelve million weekly downloads on one of them alone.

Around the same time, Google announced AI-discovered zero-days are no longer theoretical.

These aren't isolated incidents. They're a pattern. And the pattern tells you something important.

What the attackers are actually attacking

None of these attacks found a flaw in the source code of the package. The code wasn't the problem.

The TanStack attackers didn't steal any credentials. They didn't need to. They exploited a GitHub Actions workflow, poisoned a build cache, and pulled an OIDC token straight out of the runner's memory during a build. Then they used the project's own legitimate release pipeline to publish malicious versions. The packages even had valid cryptographic provenance attached.

Read that again. The packages were cryptographically signed as legitimate, because they came from the legitimate publishing pipeline. The attackers didn't break the lock. They walked in through a side door nobody knew was open.

This is the shift, and it isn't specific to open source. Attackers aren't going after the code. They're going after the trust chain. The build process. The CI/CD pipeline. The signing keys. The maintainer accounts. The cache. The publish workflow. The vendor's release infrastructure.

A closed-source vendor has all of the same plumbing. Build pipelines, signing keys, CI runners, release infrastructure, credentials with publish access. The attack surface is identical. The difference is you can't see it.

The code is fine. The plumbing around the code is what's leaking.

Why AI matters here

Before AI, finding these chains was hard. It required deep understanding of GitHub Actions, npm internals, OIDC token flows, vendor build systems, and how they all interact at the seams. That's a small group of people.

When AI can read documentation, map systems, and surface the gaps between trust boundaries faster than any human, that small group just got a lot bigger. Effectively infinite.

This is the part I keep saying. AI didn't replace the skill. It made the skill cheaper to apply. Anyone with a goal and a little patience can now throw AI at a problem and find weaknesses that used to take years of specialization to spot.

What does that mean for software in general? The same thing it means for the old cPanel box nobody patched. The threshold for "worth attacking" just dropped to zero, and the speed of attack just went up by an order of magnitude. Open source. Closed source. Your CRM. Your accounting platform. The marketing software your team logs into every day. All of it.

What this actually means

If you write software, here's what changes.

You can't just install a package and forget it. You need to know what's in your supply chain. Every direct dependency. Every transitive one. Pinned versions, not floating ones. Lock files committed. Install scripts disabled by default where you can get away with it.

You need to assume the publish pipeline is part of your security perimeter, not separate from it. Two-factor on every account that can push code. Tokens scoped narrowly. OIDC bindings reviewed. Build processes treated like production systems, because that's exactly what they are.

You need to slow down updates. Most of these compromises were caught quickly. CISA now recommends not installing any package that hasn't been published for at least seven days. That sounds like a small change. It will catch the vast majority of these attacks before they reach you.

If you run a business that depends on software but doesn't build it, here's what changes.

You're in a supply chain whether you know it or not. Every tool you log into runs on code somebody else wrote, built on a pipeline somebody else maintains. When that pipeline gets compromised, you inherit the problem.

Ask your vendors about their supply chain. Not their security policy. Their supply chain. Where do their dependencies come from? When do they update? Who has access to push code? How do they verify a build is what they think it is?

If they can't answer those questions, that's the answer.

What hasn't changed

The fundamentals.

I've been saying this my whole career, and it's still true. Know what you own. Patch what you use. Don't trust what you can't verify. Two-factor everything. Least privilege everywhere. Keep things simple enough that you can actually understand them.

These rules apply to every piece of software your business touches. Free or paid. Open or closed. The ones you write and the ones you buy.

The attackers got faster. The plumbing got more complicated. The basics are still the basics.

Open source isn't broken. The trust around it needs work. So does the trust around everything else we run on. That's a fixable problem. It's also a permanent one. Trust isn't something you build once. It's something you maintain.

We're going to look back on this period as when software supply chains grew up. The technology was already mature. The operational practices around it weren't. They will be, because they have to be.

Keep building. Just pay attention to what you're building on.