Jono Alderson Kalicube Summit 2026 session

Jono Alderson on the Push Layer — DSCRI, IndexNow, MCP, and the WebMCP Question

ByBernadeth Brusola

Session identifier

  • Session: Push Layer and the Five Entry Modes
  • Day: 1 (June 24, 2026)
  • Speaker: Technical SEO Consultant and Software Engineer, Meta
  • Framework concept: DSCRI — the five-gate Record phase of the AI Engine Pipeline (Discovered, Selected, Crawled, Rendered, Indexed), the infrastructure layer that determines whether anything that follows in the pipeline is even possible
  • SEL article: The push layer returns: Why ‘publish and wait’ is half a strategy

Speaker bio

Jono Alderson is a globally recognised technical SEO expert and software engineer based in York, England. He is currently embedded at Meta via Magnit, where he applies SEO, analytics, and web-performance engineering to large-scale products. His career includes senior roles at Yoast as Head of SEO and Distilled as Principal Consultant, and he operates his independent technical SEO practice Applied Energistics. Jono is a WordPress core contributor, a contributor to the Web Almanac, board member at The WP Community Collective, and co-founder of Days Of The Year. He has advised the AMP project and is a frequent keynote speaker at BrightonSEO, SMX, and international conferences, known for technically sophisticated arguments about where website infrastructure decisions have strategic business consequences. Jono is happiest neck-deep in code, then on stage explaining what it means.

Session’s place in the Kalicube Framework

Jono’s first session covers DSCRI and the Push Layer — the five-gate Record phase of the AI Engine Pipeline where bots learn about a brand, and the five entry modes through which content enters the algorithmic ecosystem. Most brands rely on Pull — publish and wait for a crawler to find it. The other four modes are active and have to be deliberately engineered. DSCRI is the infrastructure layer that determines whether anything that follows is even possible: a brand that fails at Discover or Select never reaches the algorithm. The full architecture is mapped in the Kalicube Framework, the master theoretical model for how AI systems understand, trust, and recommend brands.

Episode summary

Jono Alderson opens with the render phase — the element of DSCRI that most practitioners underestimate and most LLMs skip entirely. The modern web is not static: most of what a page contains loads on the user’s device after the server response, which means retrieving the HTML is not the same as retrieving the content. Rendering requires experiencing the page as a user would, executing the JavaScript, comparing the pre-rendered and post-rendered versions, and following the new links and content that rendering reveals. This is why Google spent a decade normalising rendering at scale, and why almost all LLMs default to fetching only the server response. The practical consequence Jono identified is a structural dependency that will persist for years: LLMs will rely on Google and Bing’s rendering infrastructure because building equivalent infrastructure independently is prohibitively expensive and complex.

The IndexNow section was the session’s most structurally honest contribution on the crawl economy. IndexNow solves real inefficiency — brands ping a signal directly instead of hoping crawlers find new content. But Jono named the systemic problem with mass adoption: if every site on the planet submits on every update, the submission queue becomes the crawl queue and nothing is gained. Google’s reluctance to adopt it is not incompetence — it is a recognition that push-based models at internet scale require completely rebuilt resource allocation architecture, and that spam and bad actors get a direct routing mechanism. Bing’s adoption makes sense given its smaller crawl budget; Google’s hesitation is rational.

The MCP section was the session’s most forward-looking contribution. MCP is the evolution of the API modality for a world where machines communicate in natural language rather than explicit code. Where traditional APIs require predefined hooks and explicit coding, MCP allows an LLM to ask what a website can do, interpret the response, and act on it. Jono’s instruction was to stop thinking about websites as marketing pamphlets and start thinking about them as service interfaces: what tasks can my website perform for an agent? A dentist’s website could book appointments, assist with diagnoses, answer patient questions. Codifying those capabilities in MCP terms is the practical implementation of what the Kalicube Framework calls the Codified stage — making the business machine-readable at the service level, not just the content level.

The WebMCP skepticism was the session’s most technically precise contribution. Dave Davies’s live demonstration showed fifty-four cents and ninety seconds to fill a form without WebMCP versus less than one cent and two seconds with it — that is the financial case. Jono acknowledged it but named two structural problems. First: WebMCP assumes agents will interact with websites from the front end like humans, rather than hitting an MCP endpoint directly. If agents evolve toward endpoint interaction rather than visual form-filling, WebMCP solves a problem that will not exist. Second: WebMCP requires developers to add markup around existing elements, which recreates the brittle inline annotation problem that made early Schema.org implementations a maintenance disaster. The same developers who built the bad form will maintain the WebMCP markup around it, and they will break it. Jono’s verdict was not dismissal but honest uncertainty: it is a Betamax versus VHS moment, and the outcome depends on which interaction model agents settle into.

The session’s most repeatable contribution was its closing framework: enterprises — be organized; smaller businesses — be interesting. Enterprises fail at the DSCRI layer because their websites are architectural disasters. The discipline is managing what should be discoverable, selectable, and indexable at scale. Smaller businesses fail differently: they have pages about their services that are structurally identical to a trillion other pages about the same services. The solution is not more pages — it is being genuinely opinionated, divisive, funny, or emotive in a way that large companies cannot. Interesting content skips the evaluation queue because it already answers the question the algorithm is asking.

Key quotes

“Almost all LLMs and AI tools are just fetching the server response — they’re saying ‘give me the HTML’ and that’s it. So they’re missing a whole bunch of the picture.” Jono Alderson, on why the render phase creates a structural LLM dependency on Google and Bing’s indexes that will persist for years.”

“Most websites today are still just marketing pamphlets. But when you start to say, what can my website do — if you’re a dentist, why shouldn’t an LLM be able to book an appointment from a calendar? These are things a website could do.” Jono Alderson, on the shift from website as content to website as service interface.”

“The same developers who did a bad job of building the form will be the ones maintaining the WebMCP markup. The same kind of brittleness will persist throughout all of this.” Jono Alderson, on why WebMCP may recreate the inline Schema.org maintenance problem rather than solve it.”

“Enterprises — be organized. Smaller businesses — be interesting.” Jono Alderson and Jason Barnard, arriving at the sharpest summary of the DSCRI failure modes for different types of businesses.”

“There is a real opportunity for small businesses to outmaneuver big companies by being interesting in a way that big companies can’t. That skips you a whole bunch of the system deciding whether you should be indexed and evaluated and recommended, because you’ve already done something far better than anyone else.” Jono Alderson, on why genuinely differentiated content bypasses the evaluation queue.”

Further reading

The push layer returns: Why ‘publish and wait’ is half a strategy, Article 7 of Jason Barnard at Kalicube’s Search Engine Land series on AI search architecture. The article maps the five entry modes through which content enters the algorithmic ecosystem and names the Pull-mode dependency that Jono’s session addresses from the engineering vantage.

Related sessions

Link to preview post

This session was previewed here before the Summit.

Link to speaker post

About Jono Alderson

Links to session clips

WebMCP Will Break Like Schema Did: Jono Alderson’s Contrarian Take at Kalicube Summit

Why Your Website Is Still Just a Marketing Pamphlet: Jono Alderson

Transcript for Jono Alderson on the Push Layer — DSCRI, IndexNow, MCP, and the WebMCP Question

Jason Barnard: Hi, welcome to this session with Jono Alderson. Jono, welcome.

Jono Alderson: Thank you very much for having me. How exciting.

Jason Barnard: I love talking to you. You’re always teaching me stuff — you’re the geeky guy who gets the bigger picture.

Jono Alderson: I wonder where that was going for a second, but I’ll take that.

Jason Barnard: Brilliant. You’ve taught me so much over the years. I’m super happy to be talking to you about the bots and the algorithms. Just to remind everybody: as we’ve gone through these sessions, we have the bots that record, the algorithms that activate, and that’s what we’re talking about. Also how you feed the bots — through the traditional bots that crawl, IndexNow, MCP, and WebMCP — and then hopefully annotation and the Algorithmic Trinity.

First of all, DSCRI is Discover, Select, Crawl, Render, Index — rather than just crawl and index. Give me your overview of that.

Jono Alderson: The render bit is the interesting bit, because that’s the newer element. For a long time, the mental model was just discover, crawl, index. And this render bit adds a whole bunch of complexity, because it turns out that the modern web is more than just static words on static pages. A lot of it is complicated, interactive, often JavaScript-powered content that loads at least partially — and often completely — on the user’s device after the server response. So if you just had crawl and index, all you get is the shell — the framework, the wrapper — and you never get all the content that the software would load, which is why most websites when you load them have all those loading spinners. That rendering phase is what produces most of the actual content.

So we now have a paradigm where if you want to understand what’s on a page — because you want to ingest it, evaluate it, rank it, recommend it — it’s not enough just to retrieve it and index it. You also have to render it, parse it, and compare both versions, because you don’t know which is right: the pre-rendered or the post-rendered version. That adds an extra level of complexity where you have to experience the thing the way a user would in order to extract all the content and context. And that makes the whole first half of the funnel tricky — the whole retrieval process becomes more complicated because in the process of evaluating that rendered surface, you might find a bunch of links or a whole bunch of interactive content that reveals more content. The whole thing has this extra layer of dimensionality.

Jason Barnard: And that makes me think about the fact that LLM bots generally don’t render. And this is why it’s suddenly become very interesting.

Jono Alderson: Yes. Almost all LLMs and AI tools are just fetching the server response — they’re saying “give me the HTML” and that’s it. So they’re missing a whole bunch of the picture. I don’t see a world where that changes anytime soon. The amount of technical complexity and cost involved in rendering versus just retrieving is enormous, and that’s why it’s taken Google a decade to normalize doing that. Then there’s the additional overhead of the reconciliation piece: how do I compare the server response to the rendered response, what’s the difference, which one should I trust? That’s ten times the complexity and cost on top of that.

So you’ve got all this extra overhead, which is why most LLMs we see are still relying very heavily on either Google or Bing’s index, because those indexes have already done the work of rendering. There’s this weird dependency and crutch where LLMs, certainly for the long term, will not render, and will be reliant on retrieval and RAG from search engines that do. There’s a weird synergistic relationship there.

Jason Barnard: So basically the big two — Google and Bing — their indexes are going to be dominant for years to come.

Jono Alderson: Yep. And then what happens when they’ve used the index to decide what to show, and then they go and crawl the content to follow up? They don’t get the same content. There’s a problem there. Or they’re crawling their own cached version. Every couple of weeks there’s a piece of news that comes out saying maybe ChatGPT is building its own search crawler, maybe Anthropic has its own index. It actually looks increasingly like what’s happening is they’re just saving and storing cached rendered versions of content they’ve already seen. So when they want to explore pages and content, they can look up saved versions of the rendered version rather than just requesting the empty shell. Which makes total sense for them, but also means it’s unreliable in terms of which content they’re actually retrieving, and it’s probably stale.

Jason Barnard: Lovely. The whole diagram — and I showed you this before the show — talks about this as an entire cycle. The Kalicube Flywheel takes your business and feeds it back into DSCRI — recording by the bot through traditional bots, IndexNow, MCP, and WebMCP. Can you walk me through those four technologies and how they shortcut the process?

Jono Alderson: Sure. So the traditional bots thing: you publish a piece of content at a URL and you hope it gets discovered and evaluated. Maybe you can signpost that through XML sitemaps, internal linking, but you’re essentially beholden to spray and pray, hoping that something finds it.

Then we see the first big evolution of that, which was Microsoft’s IndexNow, where you say: instead of waiting and hoping that something comes and finds this at the point of publish or update or delete, you ping off a signal to whatever the vendor is — whether it’s Bing or some middleware — and those systems go: okay, a thing has happened, now let’s go and look at it. That’s super interesting because in theory it means all the wastefulness of inefficient crawling goes away. Traditional crawling is super inefficient — you fire up a whole bunch of machines, create a whole bunch of crawlers and robots and scripts, and you go out and explore, and ninety percent of what you find is a broken CSS file or another duplicate of page five of the same blog. None of it is useful, so then you have to do huge amounts of work to reconcile and filter it. A lot of that goes away with IndexNow.

Jason Barnard: One point about that — Fabrice Canel was saying they solve some of that with Select. They don’t select if they can predict that on the other side it’s going to be something broken or duplicated.

Jono Alderson: Yes, isn’t that interesting. And Google does the inverse as well — it will look at patterns and go, it looks like you might have pagination here, let’s go and proactively explore and seek it out. So you get all sorts of weird emergent behaviors with exploration. Either way, it’s all very costly and very inefficient. Bing would certainly like to do a lot less of that.

So you moved from traditional crawling to IndexNow. Google haven’t adopted it — do you think they ever will, or is that a lost cause?

Jason Barnard: I think it might be a lost cause.

Jono Alderson: The risk with it is that sufficient adoption at scale puts you back where you started, because you move from a crawl queue just to a submission queue. If every site on the planet starts pinging Google every time they hit update on a post, you still have the same questions of resource allocation and prioritization. But you’ve also given a direct routine for all the spammers and bad actors. At the moment, Google can do some degree of predictive evaluation — let’s not crawl this domain because it looks dodgy. Whereas you’d have to reinvent all of the architecture for a push-based model. So I would like them to adopt it, I think it has some advantages, but it would be quite a big change for them. And they’re famously not great in this space.

So onto MCP. This is maybe the biggest thing ever — or maybe nothing at all, we’ll see. Ten years ago, if I want to code an integration between two pieces of software, I connect up via APIs. I write a piece of script that makes a connection to a third-party exposed endpoint on a piece of software that has some logic in it that then gives it instructions. Almost all software on the web that talks to other software is built on this premise — we have these predefined hooks and this thing can talk to that thing in a predictable way.

Now we get LLMs and AIs, and the way we interact with those is fluffy and ambiguous — through human language rather than explicit coding. So you need a format by which, if I ask my LLM to go and update a blog post on my website or add a product to my shopping cart, the LLM needs to know how to do that. It needs to understand the methods by which websites work and what can and can’t be done. And then that website needs to know how to interpret those requests and turn them back into code.

MCP is the evolution of the API modality to allow LLMs to fuzzily talk to websites. I can define the tools and tasks and things my website can do. And then anyone using an LLM or a chatbot or whatever can ask plain language questions of that, and it can interpret and turn them back into a request, and then pipe stuff back out as well. So you start to codify what are the tasks and tools my website can do. Most websites today are still just marketing pamphlets. But when you start to say, what can my website do — if you’re a dentist, why shouldn’t an LLM be able to book an appointment from a calendar that manages all the availability, or help provide a diagnosis for a toothache? These are things a website could do. And now we start to see LLMs and agents acting on behalf of users. Start to think about what services your website provides to bots — it’s quite an interesting area to explore.

Jason Barnard: I love that. And you used the word “codify,” which is the last part of Serve. What I’m saying is: do your business as your business, serve your clients, make sure they’re happy, make sure they’re advocating for you, take all of that business operations and codify it, then push it back to the bots and MCP. What you’ve just said to me — and I really like it — is you can use MCP to ask yourself: what do I need to codify? What would be useful to codify in order to educate the algorithms, which is my big thing — but also to offer services, which is the part you’ve just added.

Jono Alderson: Yes. I think that codification of business is a bit that everyone has somewhat skipped over, and it’s going to be super important in years to come. How do chatbots and agents and LLMs understand what you do, and then how do they interact with it? What are the things you sell? How much do they cost? How do you interact? Getting those things really clearly defined is super important. Which brings us on to WebMCP — and I am a little skeptical.

Jason Barnard: Yeah. I’ll just tell you a little story, because I just had a conversation with Dave Davies and he’s built a little machine that compares an AI trying to fill in a form without WebMCP. It cost fifty cents in tokens and took about a minute and a half, and he did it live on the show. Then he did it with WebMCP and it cost less than half a cent and took two seconds. So he’s saying WebMCP is going to be a super advantage, assuming it gets adopted, because the cost for the engines to actually fill in forms and interact with your website is going to go right down — which makes you much more friendly and inviting for the algorithms.

Jono Alderson: I agree in principle, and I think this is super interesting. But I’ve got two angles where I think it might not become the next big thing — and this is still very early days.

One is that it assumes the agent will be interacting with your website from the front end, like a human would, and that’s not necessarily the case. There are some interesting discussions at the moment about the pros and cons of having an agent-facing version of my website — raw code, Markdown, stripped-back HTML — versus having just the human version and having agents experience and interact with it in the same way a human might. There are pros and cons to both. It’s a really interesting debate. But WebMCP very much assumes the agent will load the web page, look at it visually, click into the form, do the steps — which is quite an expensive and complicated way for agents to interact when they could, for example, just hit an MCP endpoint. It’s a Betamax versus VHS moment, and it depends which way it goes.

The other concern is that the mechanics of WebMCP are essentially: add markup to your code. Instead of just having a form, I have a form with a whole bunch of extra code in it that says: this is an email input, you need to put an email address in here, don’t try to click the submit button until you’ve filled out the thing — explicit instructions for machines that decorate the things they can interact with.

And there are two problems with that. One is that it’s duplicative — having to describe the form around the form feels cumbersome. Is that a short-term limitation that goes away as these systems get smarter? Maybe. But the more interesting challenge is: people are going to mess this up.

If we go back to 2011 and the very birth of Schema.org as a mainstream thing, the main way you implemented structured data wasn’t via a nice neat piece of JSON like you would today — you’d mark up and decorate all the individual things. You’d go into your HTML and say: this bit is an address, this bit is the street in the address, this bit is the postcode. And it would break all the time because developers aren’t very good. If we’re saying that WebMCP is meant to fix the problem of badly built forms that are hard to interact with, the solution can’t be to get the same people who did a bad job of building the form to make the form more complicated. The same kind of brittleness will persist throughout all of this. We’ve had fifteen years of proving that this kind of micro-markup inline just breaks because developers aren’t good enough.

Jason Barnard: And that’s an incredibly good point. I switched from inline to JSON as soon as I could. Is there not the same thing possible here — that you can simply identify the element and use JSON?

Jono Alderson: In theory, yes, and there are ways to do that. But then you’re also reliant on when the developer goes in and changes the form — because you’ve said, add a subject dropdown — but they don’t update the JSON. So now they’re maintaining it in two places. The people are always the brittle breaking point.

Jason Barnard: And there’s another question — I’m going to be talking to Kasper Kulikowski from Google, who’s building the agentic side of Chrome. Google Chrome is being built with agentic capabilities to be able to act and act on behalf of third parties. What do you think is going to happen there?

Jono Alderson: I think that’s super exciting. I caught wind of the very early phases of this a few years ago, and it just became mainstream about last week — it turns out that Google Chrome is now shipping a four-gigabyte local model to your laptop. Unless you explicitly opt out or don’t have the space, your laptop probably already has a local model running in Chrome. Some of the early discussions around that were super interesting — things like, any time there’s a form on the page, if you right-click into the content area, rather than having to type, you could just activate your local AI to agentically complete it for you. You start to get a fancier version of autocomplete, but then you start to go beyond that. Why can’t it summarize pages? Why can’t it evaluate things across multiple tabs? Why can’t it make decisions on your behalf? And you start to see Chrome less as a browser and more as a kind of operating system for productivity.

That’s been hard to do so far because it’s expensive to do all of that back and forth to the cloud. But now if everybody’s got a reasonably decent model running locally, it can start to be intelligent. It can start to personalize. It can start to make proactive recommendations. All sorts of cool stuff coming down the pipeline.

But if I’ve got a local intelligence on my machine because I haven’t opted out — that solves Dave’s issue of fifty cents per interaction. Maybe it still runs in the background in an invisible tab and takes a minute and a half, and it probably heats up your laptop unpleasantly. But it definitely moves part of the problem.

Jason Barnard: Can you explain: you said four gigabytes if you don’t opt out. What is the system and exactly how does it work?

Jono Alderson: If you have enough space on your laptop and you’re running a reasonably recent version of Chrome, it silently and invisibly in the background downloads a local model for text generation. I don’t think it’s plugged into anything yet, but it’s now there and can be utilized. So subsequent updates of Chrome — I would not be surprised to see buttons that say “summarize this” or “autofill this.” It’s been hugely contentious, because when the spec was originally proposed several years ago, Microsoft, Firefox, Opera, and others all went: no, this is problematic, it’s invasive, it’s non-permissioned, it’s a huge amount of storage, the transfer cost of that to a billion laptops is a rainforest. And Google went ahead and did it anyway. So there’s some politics around this. But now that it’s done — yeah, super interesting capabilities.

Jason Barnard: And Fabrice Canel, when he pushed out IndexNow, was saying a big part of this is trying to reduce the carbon footprint.

Jono Alderson: Yes. Cooling is so inefficient.

Jason Barnard: So wrapping up this particular part — the bots part, the DSCRI — looking at enterprises and smaller companies: where are they most stuck, and what should their focus be?

Jono Alderson: Tricky. For enterprises, it’s almost always that their websites are a broken mess. They’ll have twenty-three different subdomains, a hundred APIs, all sorts of JavaScript, and different teams. When you say to Google or a chatbot: go and crawl this, evaluate it, render it, it’s a nightmare. Wading through all of that, understanding what’s what, which bits you’re allowed in, which bits you’re not, whether you should really be crawling all this API stuff a million times a day unnecessarily — it all gets very, very messy. And enterprises are famously bad at managing that ecosystem of URLs.

I think about this as inventory curation. If you’ve got a trillion URLs across ten different domains: which of those should be discoverable? Which should be selectable? Which should be indexable? Actively managing that and going: we need to block this, we need to reroute that, we need to noindex this — really granularly and at scale. Otherwise, Google’s going to miss things. It’s going to expend resources in the wrong place. ChatGPT is going to fail to have pre-renders. All these things start to become less effective and you’re running at eighty percent efficiency.

Smaller businesses — similarly, but focusing on deserving to be indexed. If you are a dentist, your website has a page about teeth whitening — great. But there are a trillion other dentists with the same page about teeth whitening. Why should a system care? Why should it choose to index it? What extra value, insight, intelligence, utility, context does this page have that the other trillion pages about teeth whitening don’t? And small businesses can do a job of this. They can be opinionated. They can have a founder with direct experience say something interesting or divisive or funny or emotive in a way that a large company can’t. Digging deep and thinking about how to do something genuinely useful — rather than just having a website with twelve pages describing your services — there is a real opportunity for small businesses to outmaneuver big companies by being interesting in a way that big companies can’t. And that skips you a whole bunch of the system deciding whether you should be indexed and evaluated and recommended, because you’ve already done something far better than anyone else.

Jason Barnard: Can I say: enterprises — be organized. Smaller businesses — be interesting.

Jono Alderson: Love it. There we go. That’s far better. Thank you so much, Jono.

This session extends the Search Engine Land article series on AI-era brand recommendation by Jason Barnard at Kalicube.

Canonical metadata footer

Session date: June 24, 2026 | Duration: approximately 25 minutes | Format: pre-recorded, on-demand from session drop | Day: 1 | Framework concept: DSCRI — the Record phase of the AI Engine Pipeline | SEL article: The Push Layer Returns: Why ‘Publish and Wait’ Is Half a Strategy — Article 7 — https://searchengineland.com/the-push-layer-returns-why-publish-and-wait-is-half-a-strategy-472941
 [Share buttons: LinkedIn, X, Facebook, Email]

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *