A question has been doing the rounds recently: do we actually need site search?

It’s a fair question and one I have been giving a lot of thought to. With AI-powered summaries increasingly answering queries before users even reach a website, and with navigation that, when it works, can get people where they need to go, it’s reasonable to ask whether a search box is still earning its place.

I want to make the case that not only do we still need it, but that there is more we could be doing to hear what it is telling us, and that in a changing web landscape, the stakes of getting this right are higher than they might appear. This is my take on that question.

The visitors who remain are asking harder questions

AI-powered search, Google’s AI Overviews, Bing’s Copilot, and a growing ecosystem of assistants are increasingly handling the easy, surface-level queries. What are the entry requirements? Where is the main library? When does the term start? Users may well be getting their answers without ever clicking through to a website.

The people who do arrive are doing something more complex. They’re navigating nuance, completing a task, or looking for something specific that a summary couldn’t resolve. They are, almost by definition, higher-intent users, and they are maybe more likely to reach for the site search to find what they need.

This is where the opportunity lives. But there’s a subtler risk worth naming first.

We don’t control what AI says about us, but we control what happens when someone arrives

When a user asks “how much does it cost to study at the University of Edinburgh?” in Google or Bing, the AI summary doesn’t necessarily draw from our content. It synthesises from whatever it finds, and that might include a comparison page from a competitor institution that frames us as the expensive option, or an aggregator working from outdated figures. The user absorbs that framing before they’ve visited us at all.

This matters because users arrive with expectations already shaped. If our site then delivers a confusing, hard-to-navigate experience that doesn’t quickly surface authoritative answers to the questions they came with, we’ve failed twice: once in the AI layer we don’t control, and once on our own platform where we do control the content.

A strong on-site search experience is part of the answer. When users can quickly find accurate, up-to-date information on our platform, in our voice, with our context, we’re not just serving them better. We’re giving them a reason to trust our content over whatever summary brought them here. That matters especially for high-stakes queries around fees, entry requirements, and outcomes, where a third-party framing in an AI summary could genuinely influence a decision.

But here’s the question I keep coming back to: how would we know whether we’re actually delivering that? How confident are we that when someone arrives and searches for fee information, or scholarship options, or how to apply, they’re getting a result that reflects our best, most accurate content and not something buried, outdated, or missing entirely?

That’s where site search starts to feel like something more than a navigation tool.

Site search as a content performance monitor

A search tool you control gives you a feedback loop that no external analytics can replicate. Search logs tell you what people came looking for and couldn’t find through your navigation or from an AI summary. That’s not just useful data, it’s a content audit running continuously, written by your users.

Queries with no good results point towards content gaps. Repeated searches for the same thing might signal a labelling or findability problem. High search volume on a topic you thought was well-covered could mean the content exists but isn’t structured in a way that surfaces it.

Unlike external analytics, which tells you what happened, site search logs can tell you why: what someone was trying to do when they gave up, clicked away, or drilled deeper.

Interrogating both sides of the search

The real power, as I see it, comes from owning the full picture: what goes in, and what comes out.

On the input side, you have user queries, unfiltered, unsanitised, and often surprisingly candid about what your content is missing or getting wrong.

On the output side, you have the results your search returns: which content is being surfaced, how confidently, and whether it’s actually relevant. A query returning weak or irrelevant results is a signal. A query returning nothing is a louder one.

When you can interrogate both ends of that pipeline, you can start to close the loop. You can identify underperforming content before a user gives up on it. You can spot where your taxonomy doesn’t match how people actually talk about things. You can track whether content improvements change what gets returned for a given query. And critically, you can start to test whether your most important content is performing as you’d hope, including the answers to the questions AI is already being asked about you.

This feels like a feedback mechanism that no external tool can give you, grounded in what your users searched for, on your platform, against your content.

There is an argument that site search itself could go further, using ELM to surface AI-generated summaries grounded in our own content, rather than leaving that layer entirely to Google and Bing. But that is a conversation for another post.

Content quality sits at the foundation

Site search can surface problems, but fixing them is a separate conversation, one about content ownership, editorial process, and where responsibility sits. What site search data can change is the evidence base for that conversation. Instead of relying on assumptions about what content is needed, or waiting for user feedback to trickle in, there’s a continuous signal available.

Good titles, clear headings, accurate metadata, and well-structured content aren’t just best practices. They’re what make that signal readable. The better the content is structured, the more faithfully a search tool can reflect what’s actually there, and the more useful its logs become as a diagnostic. It also stands to reason that when AI systems draw on that content, they’re drawing on something accurate and well-framed, rather than leaving the field open to whoever has structured their content better.

Rethinking what success looks like

If AI is handling the top of the funnel, raw session volumes seem to me to be an increasingly unreliable measure of whether a web presence is doing its job. Site search offers a different kind of evidence: did people find what they were looking for? What were they looking for that wasn’t there? Where did the content let them down?

These feel closer to the questions that actually matter, and a well-instrumented site search can start to surface them.

Back to the question

So, do we need site search?

My view is yes, but perhaps not only for the reason you might expect. It’s one of the few tools we control that can tell us, in our users’ own words, what our content is and isn’t doing. When users arrive, already primed by AI summaries we had no hand in, it’s often the fastest route to the authoritative answer we’d want them to find. And without it, we’re largely guessing whether our most important content is performing as we’d intend.

In a web landscape where external signals are becoming less reliable, that feedback loop seems more valuable, not less.

The question isn’t whether we need it. It’s whether we’re actually listening to what it’s telling us.

After Stratos’s blog post last week, I revisited Joshua Mitchell’s experiment asking an AI to simulate what using a screen reader actually feels like, not to replace proper testing, but to generate a transcript of the experience that could be shared with stakeholders who had never encountered one. The results were striking: skip links that went nowhere, navigation menus entirely unreachable by keyboard, and link text repeated identically ten times with no distinguishing context.

Stratos’s post asked whether AI is improving or impeding web accessibility, and ended with an open question to the community: are you already using AI in your accessibility workflows?

I’d just come back from DrupalCamp England, where I’d presented a talk called “Same Image, Different Story”, one I first gave at DrupalCamp Scotland, and will be taking to Drupal Dev Days later this year. It’s a talk I’m deliberately treating as a work in progress, updating it with new thinking and developments each time rather than delivering the same version twice.

And I think I might have part of an answer to Stratos’s question, though it’s more of a diagnosis than a solution, at least for now.

The problem hiding in plain sight

Harvard’s Digital Accessibility Services has a useful guide on writing alt text that includes a section called “Consider the Context.” It shows the same photograph of Hollis Hall used in two different articles. One is about students enjoying the spring weather, and the other is about the building’s famous residents, and it demonstrates that each use case demands entirely different alt text. Same image, different story.

It’s a compelling illustration of best practice and is the cornerstone of my talk. That single example, two articles, one image, two completely different appropriate descriptions, captures the problem more precisely than any technical explanation I could give. But it also quietly exposes an architectural gap: most content management systems, including Drupal, the platform that powers the University of Edinburgh’s EdWeb 2, don’t give editors anywhere to act on that guidance. The image gets a single alt text field. One description, stored once, is applied everywhere the image is used. An article about student life. A seasonal blog post. A facilities page. The same text, regardless of which detail is editorially significant in each context.

This isn’t a quirk of how one editor set things up. It’s a fundamental constraint of how Drupal’s media architecture works. And the consequences reach further than you might expect.

The anti-pattern that reveals the problem

When Drupal introduced the Media Library, it was framed as a shared asset pool designed to encourage image reuse and reduce duplication, and the intent was good. Upload once, use everywhere. But what we’ve observed in practice is editors quietly working around it: uploading the same image multiple times under different filenames, just so they can have different alt text, or set a different focal point, for different editorial contexts.

The platform designed to reduce duplication is inadvertently encouraging it. That’s a significant signal. When users consistently work around a feature, it usually means the feature doesn’t match how they actually need to work.

Where does AI fit into this?

Stratos’s post noted that AI-generated alt text is improving, but inconsistent, and the W3C’s own work on machine learning accessibility is honest about the gap. A bar chart described as simply “a graph with coloured bars” versus one that explains the data in full is the difference between access and exclusion.

There are already Drupal community contributions that tackle this, and they’re genuinely promising. AI may be able to offer a better first draft of alt text to editors to update manually, especially under time pressure.

But here’s the thing that my talk kept circling back to: even if AI could generate better alt text, Drupal has nowhere contextual to put it.

If the media architecture only supports one alt text value per image, then it doesn’t matter how good the AI generation is. The result still gets flattened to a single description, applied in every context, whether it’s appropriate or not. You haven’t solved the accessibility problem; you’ve just automated the production of the wrong answer, faster.

There’s a further constraint worth naming, too: current AI alt text tools work from the image alone. They don’t read the surrounding page content, the article headline, the body copy, or the editorial context, so they have no way of knowing whether the focus should be the students, the architecture, or the changing seasons. The next step in making this genuinely useful is finding ways to pass that subject matter to the AI, so it can generate alt text that’s not just accurate, but relevant to the specific editorial context it’s being placed in.

A practical step we could take today

There’s something worth drawing from Joshua Mitchell’s experiment here. He didn’t ask AI to fix the screen reader experience; he asked it to describe it, making an abstract problem visible and actionable.

We could apply the same thinking to alt text validation. Rather than waiting for the architecture to catch up, AI could be pointed at an existing page and asked to interrogate it: does this alt text accurately describe the image? Does it make sense in the context of this article? Is it serving the reader, or just technically present?

That’s a use case that’s achievable right now, without any changes to how Drupal stores media. And given that EdWeb serves over 600 subsites with around 1,500 editors, the ability to audit contextual appropriateness at scale, rather than relying on individual editors to self-assess, could make a meaningful difference.

The question I’m sitting with

The more interesting challenge, and the one I’m actively exploring at the University, isn’t “can AI write good alt text?” It’s “can we build an architecture where AI can write the right alt text for a specific editorial context, and can the CMS preserve and serve that appropriately?”

That feels like a genuinely solvable problem. The Drupal community is already moving in the right direction with contributions that allow editors to override media properties per-use rather than per-asset. Pair that with AI-assisted generation, editorial context passed as subject matter, and human review, and you start to have something that could meaningfully improve accessibility at scale, across a platform serving over 160 environments and more than 600 subsites, as EdWeb does.

This is part of a broader piece of work I’m developing at the University around AI editorial assistance, focused not on generating content, but on helping editors make better decisions: style guide compliance, accessibility checking, and contextual awareness. It’s early days, but the alt text problem feels like a good place to start.

To borrow Stratos’s framing: keeping the human in the middle means making sure the human has the right tools to make contextually appropriate decisions, not just faster ones. I’ll be updating this thinking as the talk evolves, and as the work here at Edinburgh develops. If anyone else in the Higher Education community is thinking about this, I’d love to compare notes.

On the last weekend of February, I made the trip to Salford for DrupalCamp England 2026. It is only its second year, but already an event I have found myself looking forward to returning to. I came away with a notebook full of ideas, some genuine food for thought about the direction of AI, and a renewed appreciation for what these community gatherings actually provide.

My talk: Same Image, Different Story

I co-presented “Same Image, Different Story: Why Drupal Needs Contextual Architecture” with Tony Barker. The talk grew out of an investigation into AI-assisted alt text generation in Drupal. It evolved, specifically, from the discovery that properly accessible shared images aren’t straightforward to provide. Without sufficient contextual information, AI-generated alt text tends to be descriptive rather than meaningful. A technically correct description of an image is rarely the same thing as an accessible one. The talk illustrates this with a deceptively simple example: the same image can represent entirely different things depending on context, and the alt text should reflect that choice rather than just the image itself. The same photo of Shaun Ryder, for instance, could have been used because he’s the frontman of the Happy Mondays, because he’s from Salford, or because he was at the Brit Awards, happening just down the road that same day. Three very different reasons that each require a different alt text. The talk unpacks how an architectural gap in Drupal affects accessibility compliance, editorial workflows, storage efficiency, and media management across complex platforms. The discussions it sparked afterwards were well worth the journey south, with plenty of conversation around how AI could potentially be part of the solution.

The Keynote: Augmented, Not Artificial

Dr. Phininder Balaghan delivered the keynote, “The Augmented Future: Winning with AI,” and it set the tone for much of the day’s conversation. The central argument was a reframing: stop thinking about Artificial Intelligence and start thinking about Augmented Intelligence. The distinction matters. The companies genuinely winning with AI aren’t the ones that replaced their engineers with it. Klarna, being perhaps the most cited example, had replaced 700 employees with AI before quality declined, customers revolted, and they found themselves hiring engineers again. The productivity gains are real, but they flow to skilled people, not instead of them. Tools amplify human expertise; they don’t substitute for it. As someone building AI-assisted workflows here at the University, this framing resonated strongly. Though it’s worth noting that the human cost for those caught in the middle of these experiments is often more complicated than the optimistic retelling suggests, which made Antje Lorch’s session later in the day feel like a necessary and timely counterpoint.

With three tracks running in parallel in places, there were some tough choices to make throughout the day, and I’ll admit that on at least one occasion I found myself in a talk I hadn’t actually intended to go to, a hazard of being so engrossed in a conversation that I simply followed the crowd through the nearest door. But that’s arguably the point. Some of the most valuable thinking at events like this doesn’t happen in the lecture theatre at all; it happens in the corridors, over coffee, and in those animated discussions between sessions where ideas get challenged, refined, and sometimes born entirely. The fact that there were videos recorded and released later is something I am so glad about, not least to catch the sessions I missed, planned or otherwise. Antje’s talk was one of the casualties of that scheduling conflict, however.

We Need to Talk About AI (The One I Missed)

As I said, unfortunately I didn’t manage to catch “We Need to Talk About AI” in person, but after the questions the keynote left rattling around in my head, it’s firmly on my watch list when the video appears. From the description alone it covers ground I think is really important: the environmental and energy costs of AI, the effect on global chip markets, and the implications for people in vulnerable situations who depend on services increasingly shaped by these tools. In an open source community that prides itself on values, this is exactly the kind of session that belongs at a DrupalCamp, and as someone actively building AI-assisted tools at the University, I think it’s worth sitting with those questions rather than just pressing ahead with enthusiasm. More to say on this once I’ve watched it, but it also makes me genuinely glad of the hard work going on to provide ELM.

Other Highlights

A few other sessions worth calling out. James Abrahams showcased the Flowdrop UI for Agents module, a no-code visual AI agent builder for Drupal CMS that allows anyone to build AI agents, using an AI agent, which feels like a glimpse of where things are genuinely heading. If you’ve ever seen Jamie speak, you’ll know that his talks are as much an experience as a session, his passion for the projects he champions is infectious, and it’s genuinely hard not to get swept up in the enthusiasm. Whether the technology delivers everything he promises is a question for another day, but you’ll leave the room believing it will.

Maria Young’s session on keyboard traps, focus failures, and ARIA fixes was a practical deep-dive into the accessibility edge cases that catch even experienced developers off guard.

It was also great to spend some time with University colleagues during the day, Emma Horrell gave an update on Drupal CMS covering what’s shipped, what’s coming, and the UX research driving it, while Aaron McHale presented “Growing a Team to Transform a University Website” alongside James South from manifesto, covering their multi-year collaboration to deliver a new student-centred web presence for the University of Edinburgh, and one well worth sharing with a wider audience.

People and Community

Beyond the sessions, it’s the people who make these events worth attending. Catching up with old colleagues, reconnecting with former clients from my agency days, and meeting new people who share the same passion for open source and the web. The conversations that carry on over a drink at the BrewDog social in the evening, for example, are often where the most honest and unguarded thinking happens. These are the moments that remind you why the Drupal community is something worth being part of.

Drupal in a Day (Sunday)

Sunday for me was given over to the Drupal in a Day training session, which I helped facilitate. It is a structured, hands-on introduction to Drupal for newcomers, and a genuinely excellent format, and I’m already hoping to bring it to Edinburgh. The logistics of how to run it here are in progress, and the next step is making the case properly. I hope to be able to demonstrate its value and articulate the benefits for a local audience. Beyond onboarding our existing interns, I can see real potential in opening it up to prospective interns too, by giving candidates a meaningful taste of the platform before they ever apply. Those who engage well self-select, arrive already sold on Drupal, and hit the ground running from day one. It becomes less of a training day and more of a pipeline: attracting the right people and filtering out those who aren’t the right fit, before either side has made a significant commitment. And with DrupalCamp Scotland on our doorstep, there’s an obvious opportunity to run it there too, reaching an even broader pool of prospective talent while giving something back to the local community. Who knows, maybe some other staff members will want to get involved, too. Watch this space.

The Bigger Picture

What started as a single day in Cambridge last year has grown into a full two-day programme, and the community energy that filled the venue was a reminder of why these events matter. If you’re a Drupal developer in the UK, or want to visit the UK, and you haven’t been to one yet, put DCE 2027 in your list of things to look out for next year.

Six months ago I joined the Web Development team at the University of Edinburgh. I know Drupal well, but I also know it’s like a huge bag of Lego bricks, its power lies in how those bricks have been assembled, and every codebase assembles them differently.

Testament to those who came before me, EdWeb 2 is a remarkable feat of engineering. One codebase running across over 160 environments, serving more than 600 subsites, curated by close to 1,600 editors. Getting up to speed quickly meant finding a way to navigate that complexity without getting lost in it.

Where AI proved its worth

When you’ve worked in Drupal for a while, you develop instincts. So when one of our environments started reporting slow load times, I had a hunch: somewhere, a block cache or menu cache wasn’t being set correctly, meaning every page visit was being built fresh from the server and database rather than served from a fast cached version.

The telltale signs were in the response headers for anonymous users:

x-cache: MISS, MISS, MISS, MISS and x-cache-hits: 0

I knew something was setting cache-control: max-age=0

A straightforward search of the codebase turned up nothing. This is where AI really earned its place. I described the problem, and the tool went to work scanning lines of code far faster than I ever could.

After several searches, we got there. A piece of code was, in certain circumstances, failing a check and returning false. When applied to the cache control setting, that false was being treated as 0.

This effectively switched caching off. The variable wasn’t being set to the wrong value; it wasn’t being set at all.

A targeted fix, a bit of defensive programming, and the problem was resolved. While AI helped locate the issue, the diagnosis and the fix were mine. Could I have found it manually? Eventually, probably. But describing the problem in plain language and having AI work out what to look for saved hours, if not days of scouring the codebase.

Of course, there’s no substitute for getting deep into the codebase over time, and that’s very much still the plan. But problems don’t wait for new team members to find their feet, and having AI as a tool to bridge that gap means issues can be tackled with confidence while that deeper knowledge is still being built.

The uncomfortable side of AI

I’ll be honest, I’m an advocate, but also a sceptic. I’ve been reading about the energy and water consumption of large AI data centres, and it’s hard not to feel conflicted. A data centre the size of Manhattan isn’t an abstract concern, there seems to be a real cost that sits behind every query.

The Drupal community has some vocal voices on this too, and I find myself nodding along even as I reach for these tools. That tension hasn’t gone away.

Part of that discomfort was closer to home than data centre emissions. Commercial AI tools had made themselves very easy to reach for, but reaching for them felt at odds with what I actually wanted to be doing. I knew ELM was the right choice, it just took more effort to get into my workflow. So rather than defaulting to the convenient option, I found myself holding back, using AI more sparingly than I might have otherwise.

Getting ELM Onside

The recent University’s AI Town Hall was exactly the energy injection I needed. A conversation with Andrew Hayward was the spark, hearing that others across the university were already making progress coding with ELM gave me the push to try again. Bart Pohorecki then pointed me to Codex CLI, which can be configured to work with an ELM API key, and a bit more digging led me to Codex CLI launcher built for PhpStorm. Suddenly ELM was running directly inside my IDE, with access to the codebase and no files being sent to unrestricted external services.

The result is a setup that feels like a genuine step forward: the productivity benefits I’ve come to rely on in my community projects, with considerably less of the guilt. Using a University-backed model feels meaningfully different, the privacy guardrails and University oversight address enough of the concerns that had been giving me pause.

I’m still at the early stages of exploring what ELM can do in this context, but I’m genuinely optimistic. If you’re curious about getting set up with Codex CLI and the PhpStorm plugin, feel free to get in touch, I’ll be happy to share what I’ve learned so far.

It’s also a reminder of the value of events like the AI Town Hall, tech conferences such as Scottish Web Folk, and community gatherings like DrupalCamps. They’re not just opportunities to learn what others are doing, they’re a way to recharge your own thinking and find the motivation to push past the inertia that can build up around good intentions and get some much needed excitement of experimentation.