joe.pistell said:

Remember what I said, the more complex the task, the more prone it is to 'hallucinations'. Amiee's example is complex.

AI struggles with complex MATH calculations. ALWAYS VERIFY.

Click to expand...

And... here we are, ONE YEAR LATER...​

WOW, AI is sooooo far ahead of the limitations it had one year ago. Back then, AI was a 6th grader. Today, AI is a masters graduate that is your personal intern.

What is you ONE YEAR FORECAST?
Main street hasn't fully embraced AI yet. At this current pace, where will AI be next year?

I have to give you massive credit here, your diagnosis of the legacy tech bloat is spot on. A 70% 'Poor' PageSpeed rating across the industry is embarrassing, and building a clean, SSR-first infrastructure with pristine schema is exactly what the industry needs to fix the crawl budget issues. I am genuinely looking forward to seeing those technical benchmarks for @DealerInt.

Where I think the architecture still hits a wall is your assumption about how non-Google models acquire data, specifically regarding retail velocity versus index churn.

You mentioned that GMC feeds and SSR schema are how Perplexity and OpenAI 'know' a car arrived. GMC is fantastic for Google's ecosystem, but Google isn't sharing that structured feed with OpenAI or Anthropic. For those models to discover inventory without an aggregator, they are entirely reliant on their own web crawlers hitting your SSR schema.

Even with a lightning fast site, standard web crawling is fundamentally incompatible with automotive retail velocity. While an average unit might sit for 30 to 60 days, the highly desirable, aggressively priced inventory....the exact cars users are actively querying AI for, often move in a matter of days. If a foundational model's crawler only indexes a specific VDP once a week, the AI is going to confidently send shoppers to 404 pages and sold vehicles. Models cannot tolerate that level of hallucination risk.

The 'Aggregator Tax' isn't just a visibility tax; it's a data-licensing reality. Foundational models are striking massive enterprise data deals with centralized hubs precisely because they need a real-time API firehose, not because they want to rely on crawling decentralized local domains, no matter how fast or clean your pipe is.

I completely agree that your infrastructure will absolutely crush legacy platforms on standard Google crawlability. But until OpenAI decides to trust and query thousands of decentralized MCP endpoints instead of buying a clean, normalized data feed from a centralized network, the aggregators still hold the keys to the non-Google LLM intelligence layers.

DealerInt said:

Joe, you’re right on discovery, but you’re describing the Aggregator Tax model. Global discovery and local execution are two different steps.

Perplexity, OpenAI, and Anthropic already handle global discovery (Top-of-Funnel) through their own web-scale indexes. They don't need to ping 18,000 dealers; they just need a direct handshake with the 5–10 local results that actually matter to the user.

That’s why Bright Data, Arcade.dev (WebMCP), and Hrizn are so critical—they provide the "Bottom-of-Funnel" execution layer.

Discovery tells an agent where a car might be; MCP proves it is there and lets them act. I’d rather give the "keys to the data" back to the dealer via the new W3C WebMCP standard than keep them locked in a centralized hub. Are we building for the aggregators, or for the dealers?

Click to expand...

I’m genuinely glad to see Horizon having success. Frankly, we're essentially the only two players in auto actually helping dealers solve this new AI/SEO visibility problem right now. We just go about it differently, and there’s absolutely nothing wrong with that. We both want to kill the Aggregator Tax.

But architecturally, your premise has a massive Catch-22.

You mentioned in your first post that legacy platforms are blocking non-standard bots. If Perplexity and Anthropic are blocked from crawling, how do their "web-scale indexes" magically know a red SUV arrived yesterday to put that dealer in the top 5 results?

They don't. They rely on search APIs, which rely on centralized, structured feeds. If a dealer skips the central hub and relies purely on AI bots bypassing legacy blocks to crawl their site, they’ll be invisible.

WebMCP is an incredibly exciting future for bottom-of-funnel execution, but let’s be real, it’s still highly experimental. Consumer AI agents aren't natively configured today to wander onto a local site, read an llms.txt, ingest a manifest on the fly, and autonomously execute tool calls.

We can't sell dealers on bypassing centralized discovery today just because WebMCP is the future. An elegant MCP manifest doesn't matter if the AI never knocks on the door because it didn't know the car was there to begin with. Global discovery first, local execution second.

I’d love to connect and see exactly how you guys have engineered around this discovery hurdle in the wild, or let me know if you’re planning on dropping a white paper detailing your approach!

DealerInt said:

You're 100% right that a static llms.txt is the wrong bucket for a 500-unit live feed. My point was more about using the llms.txt as the map rather than the pipe.

In a perfect setup, the llms.txt file points the agent to a dynamic discovery endpoint or an MCP manifest. That way, when an agent hits the site, it knows exactly where the 'live' documentation and toolsets live without having to guess via a standard crawl.

As for the Google documentation—there isn't an 'official' Google stamp on WebMCP for local inventory yet. It’s still very much in the proposal/early preview stage (as Ryan mentioned earlier). The reason it's exciting isn't because it replaces Merchant Center today, but because it offers a path for 'in-browser' agents to interact with a dealer's data directly, potentially bypassing the delays and 'data taxes' often imposed by the big listing aggregators and legacy website providers.

We’re essentially talking about the difference between Google indexing a feed and an AI Agent executing a search on the dealer's behalf. It’s a nuances shift, but a big one.

Click to expand...

You're talking about bottom-of-funnel execution, but you're completely skipping top-of-funnel discovery. An in-browser agent isn't going to sequentially ping 18,000 individual dealer WebMCP endpoints to find a red SUV; the latency would be absurd. It’s going to ping a centralized, normalized third-party data hub. You can build the most elegant MCP manifest in the world, but if the agent doesn't already know your specific dealership holds the inventory via the primary search index or a major aggregator, it’s never going to show up to read your llms.txt map in the first place.

How exactly are you planning to pass a live, 500-vehicle inventory feed with real-time pricing updates through a static llm.txt file, and can you point to any documentation where Google states they use WebMCP to index local inventory for AI Overviews rather than standard Merchant feeds?

DealerInt said:

While building out some new features for my own dealer SaaS project recently, I’ve run into exactly what Matt mentioned: legacy platforms stripping rich schema and blocking agents that aren't 'standard' Google bots. It’s a massive barrier for dealers who actually want to be 'the quotable source.'

To Gregg’s point about a 'testing ground'—I’d be interested in sharing some of the raw data I’m seeing regarding how AI engines are actually consuming (or failing to consume) different types of dealership inventory feeds. If we’re moving toward a conversational paradigm where a shopper asks, 'Find me a red SUV with 3rd row seating under $35k,' the dealer who wins isn't the one with the best blog—it's the one whose data isn't being throttled by their own provider.

Has anyone else here tried to force-inject a custom LLM.txt or WebMCP toolset onto a legacy dealer site yet, or are most of you just waiting for the providers to catch up?"

Click to expand...

Greg_Gifford said:

Hey moderators (@Jeff Kershner @Alex Snyder) - that post from aellycarter from Saturday is total spam - they edited the LandingGarage quoted post to insert a link to "botox in Queens" - probably ought to get that deleted...

Click to expand...

Thanks Greg - that one has been completely zapped and banned.

The SEO narrative in automotive has gotten detached from reality. There are only 2 providers actually solving this problem....OneKeel and Horizon. We both do it differently but....there is only two that actually know what we are doing and aren't making up how to solve for this.

There’s a growing trend of oversimplifying the problem, positioning simple automation and dashboards as if they solve systemic visibility challenges. They don’t.

Modern search isn’t a content posting problem. It’s an infrastructure problem.

If you’re not operating with a full-stack content engine, one that includes:

• programmatic content generation at scale
• originality and de-duplication controls (not recycled LLM output)
• a unified intelligence layer informed by real dealership data
• integrated RAG pipelines for contextual accuracy
• continuous learning loops tied to performance signals
• and orchestration across all channels and endpoints

…then you’re not solving SEO. You’re just producing more noise, and content that does nothing to move the needle.

Schema alone isn’t a strategy.
Dealer-written content isn’t scalable.
Social posts don’t move organic search in any meaningful way.

Without a connected system that aligns data, content, and distribution in real time, results will be inconsistent at best, and misleading at worst.

The industry needs to stop pretending otherwise.