Your blog shouldn't be the same twice: how I implemented content that adapts based on who reads it

My server already distinguishes between two types of visitors. When an AI agent requests a page with Accept: text/markdown, it receives clean Markdown without navigation or scripts. When a human requests it with a browser, they get full HTML with layout, images, and styles. Same URL, two different versions of the same content.

That works. But it has an obvious limitation: it treats all humans as the same type of reader. A developer arriving from Dev.to wants to see code. A designer from Dribbble wants to see UX decisions. A founder from Indie Hackers wants to see business implications. All three receive exactly the same thing.

I decided to experiment with something nobody is documenting with real code: content that adapts based on signals available in the request, without personalization frameworks, without tracking cookies, without machine learning. Just PHP reading what the browser already tells it.

What signals a PHP server has without adding anything

Before writing a line of code, I took inventory of signals available in a standard HTTP request. No JavaScript, no cookies, no login. Just what arrives in the headers.

HTTP_ACCEPT_LANGUAGE reveals the browser's preferred language. My blog already uses this to redirect to the correct content version. But it also reveals region: es-CO is not the same as es-ES.

HTTP_REFERER shows where the visitor comes from. If they come from dev.to, they're probably a developer. From medium.com, probably a general reader. From google.com with a technical query, they want specific answers.

HTTP_USER_AGENT identifies the browser and device. Mobile versus desktop changes content priorities. A mobile reader probably wants the conclusion fast. A desktop reader is probably willing to read the full article.

The experiment: collapsible sections by context

I didn't change the article content. What I changed was which sections render expanded and which collapsed, using the HTML details tag that already works without JavaScript.

The logic is simple. If the referer contains dev.to, github.com, or stackoverflow.com, sections with code blocks render expanded and narrative sections collapse. If the referer contains medium.com, linkedin.com, or a news domain, narrative sections expand and code collapses. If there's no referer or it's direct, everything shows expanded as always.

function getReaderProfile(): string {
    $referer = $_SERVER['HTTP_REFERER'] ?? '';
    $devSources = ['dev.to', 'github.com', 'stackoverflow.com', 'hashnode.com', 'qiita.com'];
    $generalSources = ['medium.com', 'linkedin.com', 'twitter.com', 'facebook.com'];
    
    foreach ($devSources as $source) {
        if (stripos($referer, $source) !== false) return 'developer';
    }
    foreach ($generalSources as $source) {
        if (stripos($referer, $source) !== false) return 'general';
    }
    return 'default';
}

The content is identical. The visual hierarchy changes. A developer sees code first. A general reader sees narrative first. Nobody loses information. The difference is what's presented as priority.

The SEO problem and how I solved it

The obvious risk is Google seeing different content than the user. That's cloaking and Google penalizes it. But what I'm doing isn't cloaking. All content is in the HTML. I only change the default state of details elements: open or closed. Google renders JavaScript and sees all content. The details tag with or without the open attribute doesn't hide content from the indexer.

What I learned from this experiment

Three observations after two weeks with this system active.

First: time on page increased 12% for visitors arriving from development platforms. Seeing code expanded first reduces friction in deciding whether the article is relevant.

Second: bounce rate didn't change significantly for any group. This confirms collapsing sections isn't perceived as missing content.

Third: the complete implementation took 45 minutes. I didn't need any library, framework, or external service. Vanilla PHP with a 20-line function and a template adjustment.

The next step I haven't implemented yet

What I described is the most basic level of adaptive content. The next level would be using the Markdown for Agents I already have to serve semantically different versions to AI agents. Not just Markdown versus HTML but content reorganized by priority for different models.

ChatGPT absorbs deep content with definitions and evidence. Perplexity prefers modular content it can decompose into fragments. Google prioritizes semantic alignment with the user's question. The data from the 602 prompts study confirms this.

The most valuable content isn't static. It's infrastructure that adapts. And the most honest way to do it is with signals the visitor is already sending, without invasive tracking, without cookies, without mandatory login. Just reading what the browser already says.