The “Third Browser” Revisited: Web Design in the Age of AI (A Hamsterdam History Lesson)

By Ethan Lazuk

Welcome to another edition of Hamsterdam History!

This is a series of posts where we look at “vintage” SEO articles to celebrate their contributors, gain historical knowledge, and discuss how things have changed (or haven’t) since.

In this edition, we’ll be looking at “Worthless Shady Criminals: A Defense Of SEO” written by Danny Sullivan for Search Engine Watch on April 28, 2005.

The article describes a tiff that happened after web design tips were presented at a conference that said websites should be search-engine friendly. It then goes on to describe that good design is not out of line with good SEO.

Danny also describes different flavors of SEO, distinguishing content-based SEO (which was good then and still today) from spammy tactics, such as stuffing keywords into alt text or hiding text to manipulate rankings.

What I’d like to focus on is the relationship between SEO (and now GEO) strategies and web design, especially in light of AI-agent accessibility considerations.

In his 2005 article, Danny also described search engines as a “third browser” where designers tested Internet Explorer and Firefox, but also needed to understand how search engines encountered their pages.

He thus framed discoverability as part of building a functional website, and his “content-based SEO” approach included removing technical barriers around existing content (not simply producing more content).

That gives us a strong bridge to today.

In the age of AI agents, a website can now be encountered through its initial HTML, a rendered browser page, an accessibility tree, or an API.

Danny’s 2005 compatibility argument still holds water, but “does the site work?” now requires more than checking its visual appearance.

JavaScript rendering is perhaps the clearest technical example of this: JavaScript can create or update content after a page arrives in the browser. That creates a potentially significant difference between what the server initially sends and what a human user eventually sees.

How content is delivered	What happens	Implication for discovery
Client-side rendering	JavaScript builds important content in the browser.	A system that only fetches the initial HTML may miss it.
Server-side rendering	The server generates HTML containing the content.	The content is available without executing browser JavaScript.
Static generation	HTML is prepared ahead of the request.	Also makes content available in the initial response.

Google executes JavaScript using Chromium and processes pages through crawling, rendering, and indexing, so Google can read JavaScript for search. However, its documentation recommends considering server-side rendering or prerendering because other bots may lack that capability.

For instance, MERJ and Vercel’s December 2024 research observed that the AI crawlers they tested (including OpenAI and Perplexity crawlers) did not execute JavaScript.

Those 2024 findings concern the crawlers tested at that time. An AI agent operating a browser can have different capabilities, including interacting with a JavaScript-powered interface (see Microsoft’s Playwright MCP documentation). That makes crawler access and agent usability related but separate considerations.

JavaScript itself is not a design mistake. However, the rendering choices we make determine which systems can access which content.

That’s an opportunity for SEO/GEO professionals and designers/developers to work together on discoverability. The goal is to deliver the essential information reliably, then enhance the experience for clients with greater capabilities.

Accessibility is another area of focus.

Danny’s article demonstrated how keyword-stuffed alt text harmed screen-reader users. That shows us how optimization can support accessibility, but it can also abuse accessibility features.

An accessibility tree, for example, represents interface elements through their roles, names, states, and relationships. Clear labels, semantic structure, and predictable interactions can make websites easier for agents to operate as well as more usable for people with disabilities. For example, a clearly labeled booking button gives people and agents more information about its purpose than an unexplained icon.

Reading Danny’s 2005 article, I’m struck by how familiar the underlying problem of alignment between design and SEO/GEO feels today.

Designers, developers, and SEO/GEOs still need to understand how their choices affect access to a website. AI just adds more ways to retrieve information and interact with interfaces, making that collaboration more consequential.

The practical questions are increasingly specific: can the system retrieve the content, preserve its meaning, identify the available actions, and complete the user’s intended task? These questions extend Danny’s 2005 argument that understanding how different systems access a website belongs in the design process. Today, that includes systems acting on a user’s behalf.

Outro

I hope you’ve enjoyed this edition of Hamsterdam History!

Stay tuned for another edition soon, or check out related history articles below.

Until next time, enjoy the vibes:

Thanks for reading. Happy optimizing!

---

Related history posts: