Dynamic Serving

TL;DR — Dynamic servingA mobile configuration where the server returns different HTML/CSS from the same URL depending on the requesting user-agent (desktop vs. mobile), signaled with the Vary: User-Agent header. is when a website uses one web address but sends a different page to phones than it does to desktops — the server looks at what device you’re on and returns different HTML. It works, but Google would rather you use responsive designA mobile configuration that serves the same HTML on the same URL to every device and uses CSS media queries to adapt the layout to the viewport. It's Google's recommended setup and requires a correct viewport meta tag to work. (one page that just re-flows to fit the screen), because dynamic serving is easy to get wrong. If you do use it, the server has to send a special Vary: User-Agent header so caches don’t hand the wrong version to the wrong person.

What dynamic serving is

There are three ways a site can handle mobile visitors:

1. Responsive design — one page, one set of HTML, and the layout re-flows to fit whatever screen you’re on. This is what Google recommends.
2. Dynamic serving — one web address, but the server sends different HTML to phones and desktops. Same URL, different page underneath.
3. Separate URLs — a whole separate mobile site on its own address, like m.example.com.

Dynamic serving is the middle option. When your browser asks for a page, it tells the server what it is — a phone, a tablet, a desktop — in something called the user-agentA user agent is the HTTP request header a client (browser, crawler, or bot) sends to identify itself. For crawlers, a short user-agent token — a substring of that string — is what robots.txt rules actually target.. With dynamic serving, the server reads that, and decides which version of the page to send back. You and someone on a laptop can type the exact same URL and get genuinely different HTML.

The Vary: User-Agent header

Here’s the catch. Because the page changes depending on the device — but the URL doesn’t — anything that caches pages (your browser, a CDN, your internet provider) could accidentally save the desktop version and then hand it to the next person, who’s on a phone. To prevent that, the server has to send a little note with every response: Vary: User-Agent. It means “the content of this page depends on the device, so don’t reuse a cached copy across different devices.” Forget that header and people (and Google) can end up seeing the wrong version.

Why Google recommends against it

Dynamic serving relies on the server correctly guessing what device you’re on from the user-agent — and that guessing is genuinely hard to keep right. New devices appear, tablets get mistaken for phones, and it’s easy to ship a desktop and a mobile version that quietly drift apart. When that happens, Google can end up seeing a broken or wrong version of your page. So Google’s advice is simple: use responsive design instead, so there’s only one version and nothing to get out of sync.

The thing people get wrong

Don’t confuse dynamic serving with “dynamic renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM..” They sound almost identical and both involve the server checking the user-agent, but they solve different problems. Dynamic serving is about giving phones and desktops different HTML. Dynamic renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM. is about giving search-engine botsA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. a pre-built version of a JavaScript-heavy page. Different thing, different Google documentation — more on that in the Advanced tab.

In 2026, dynamic serving is mostly something you’ll inherit on an older or large enterprise site, not something anyone recommends building from scratch. Want the full version — the two jobs of the Vary header, the CDN cost most guides skip, the cloaking question, and how to check if a site is using it — switch to the Advanced tab.

TL;DR — Dynamic servingA mobile configuration where the server returns different HTML/CSS from the same URL depending on the requesting user-agent (desktop vs. mobile), signaled with the Vary: User-Agent header. = same URL, different HTML/CSS per user-agentA user agent is the HTTP request header a client (browser, crawler, or bot) sends to identify itself. For crawlers, a short user-agent token — a substring of that string — is what robots.txt rules actually target., detected server-side and signaled with the Vary: User-Agent response header. It’s one of three mobile configs alongside responsive designA mobile configuration that serves the same HTML on the same URL to every device and uses CSS media queries to adapt the layout to the viewport. It's Google's recommended setup and requires a correct viewport meta tag to work. (Google’s recommendation) and separate URLs (m-dot). The Vary header does two jobs: (1) stops caches serving the wrong device’s version, and (2) historically helped GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer. discover the mobile version. It has a real cost, though — Vary: User-Agent fragments CDN cache keys across every distinct UA string, multiplying origin load. User-agent detection is error-prone (stale UA lists, tablets read as phones), and a detection bug or missing Vary can make Google see the wrong or broken version — which is where the cloaking risk actually lives. Don’t confuse it with dynamic renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM. (pre-renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM. JS for crawlersA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. — a different concept with its own doc). In 2026 it’s a legacy pattern to audit off of, not build fresh.

What dynamic serving is, precisely

Google’s own definition, from its mobile-first indexingGoogle's practice of using the mobile version of a page's content — crawled by Googlebot smartphone — for indexing and ranking. It is not a separate index and not a ranking boost. best-practices doc: “Dynamic serving: Uses the same URL regardless of device. This configuration relies on user-agent sniffing and the Vary: user-agent HTTP response header to serve a different version of the HTML to different devices.” The now-retired dedicated Google page put it even more concretely — dynamic serving is “a setup where the server responds with different HTML (and CSS) on the same URL depending on which user agentA user agent is the HTTP request header a client (browser, crawler, or bot) sends to identify itself. For crawlers, a short user-agent token — a substring of that string — is what robots.txt rules actually target. requests the page (mobile, tablet, or desktop).”

It’s one of three mobile configurations, and the cleanest way to see it is a three-row table:

Two of these three depend on the Vary header. Google is explicit that separate URLs, “like dynamic serving, this configuration relies on the user-agent and Vary HTTP headers.” Only responsive design has nothing to get out of sync — which is exactly why Google recommends it (see the responsive designA mobile configuration that serves the same HTML on the same URL to every device and uses CSS media queries to adapt the layout to the viewport. It's Google's recommended setup and requires a correct viewport meta tag to work. deep dive, and how all three fit together in the mobile SEOMobile SEO is the practice of optimizing a site so it ranks well when crawled and indexed by a mobile (smartphone) user agent and delivers a fast, usable experience on phones. Since Google completed mobile-first indexing, the mobile version is the primary version Google uses for indexing and ranking — so mobile SEO is effectively baseline SEO for every site. hub).

How it works: user-agent detection + the Vary header

The server inspects the incoming user-agent string — the identifier every client sends — decides whether it’s a mobile, tablet, or desktop device, and returns the matching HTML. Because the URL is identical for everyone, the server then has to announce that the response varies by user-agent. That’s the Vary: User-Agent header, and Google’s archived guidance is precise that it does two distinct jobs — don’t collapse them into one:

“It signals to cachingCaching stores a copy of a page or resource — in a browser, a CDN edge node, or a search crawler's own cache — so it can be served again without regenerating or re-downloading it. It isn't a direct ranking factor, but it feeds page speed and crawl efficiency. servers used in ISPs and elsewhere that they should consider the user agent when deciding whether to serve the page from cache or not. Without the Vary HTTP header, a cache may mistakenly serve mobile users the cache of the desktop HTML page or vice versa. It helps GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer. discover your mobile-optimized content faster, as a valid Vary HTTP header is one of the signals we may use to crawl URLs that serve mobile-optimized content.”

So job one is cache correctness — a pure UX/correctness concern independent of search engines — and job two is crawl discovery. Most competitor glossary pages only mention the first (or blur the two). In a real HTTP response it looks like this:

HTTP/1.1 200 OK
Content-Type: text/html
Vary: User-Agent
Content-Length: 5710

If your server already sends a Vary header for something else (like Accept-Encoding), you add User-Agent to the list rather than replacing it.

Worth separating clearly: Vary itself is a plain HTTP caching mechanism, not an SEO invention. It tells a cache which request headers to fold into the cache key so it can store the right variant — it doesn’t detect devices or understand SEO at all; your server’s user-agent logic does that separately, and Google’s crawl-discovery use of the header (job two, above) is Google’s own characterization of a signal it watches for, not a caching-protocol requirement every cache follows the same way. Send it consistently for a given URL — including on 304 Not Modified responses and any default/fallback response — or a cache can end up holding inconsistent metadata about what it’s storing.

The cost most guides skip: CDN cache fragmentation

Here’s the angle almost every ranking page misses. Vary: User-Agent is not free — it fragments your cache. A cache keys entries partly on the Vary-listed headers, so Vary: User-Agent means a separate cached copy for every distinct user-agent string that hits the site: every browser version, every OS build, every bot. That’s thousands of variants for content that only really has two or three real versions — though exactly how much reuse you lose depends on your CDN’s own cache-key handling (some normalize or group similar user-agent strings, most don’t), so there’s no single universal hit-rate loss to quote; treat any specific multiplier, including SiteGround’s below, as one vendor’s estimate rather than a guaranteed number for your stack.

SiteGround put the practical cost plainly: “With the User-Agent [header] enabled, the system will keep different copies for each combination of OS and browser version visiting your site… you will have 5-30 dynamic requests for the same 100 visits. So the very same site will use 5-30 times the resources.” And this hits crawlersA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. hard: “If such [a] bot starts crawlingCrawling is how search engines use automated bots (like Googlebot and Bingbot) to discover URLs and download pages. A page has to be crawlable to be indexed, but crawling on its own isn't a ranking factor. your site and you have the Vary: User-Agent header, each request it makes to your site would be a dynamic one and will eat up your resources.”

This isn’t new. Back in 2013, Cindy Krum warned in Search Engine Land that enterprise CDNs treated the header as a signal that content “cannot be cached or served from the CDN and must be fetched directly from your server” — potentially “rendering your CDN completely useless” for dynamically-served pages. The specific 2013 vendor behavior has changed, but the underlying tension — Vary: User-Agent fragments cache keys — is still technically real, and it’s a major reason dynamic serving fell out of favor even among sites that weren’t worried about SEO. SiteGround also makes the practical point that “most of the sites don’t actually serve different HTML for their mobile versions. It’s the responsive CSS that does all the heavy lifting” — meaning a lot of Vary: User-Agent headers in the wild are simply leftover misconfigurations on sites that are really responsive.

Is dynamic serving cloaking?

No — not inherently. The risk is about outcome and intent, not the technique. Detecting a device and serving it device-appropriate content is fine; the danger is either (a) a detection bug or missing Vary header that accidentally serves Googlebot the wrong or broken version, or (b) deliberately serving search engines meaningfully different content than users get. Google’s own archived dynamic-serving guidance was blunt about the trap:

“Be very careful of cloaking when detecting user agents… it should not be looking specifically for Googlebot. All Googlebot user agents identify themselves as specific mobile devices, and you should treat these Googlebot user agents exactly like you would treat these devices.”

The parallel is Google’s still-live dynamic rendering doc, which states the general principle for the related JS-rendering case: “As long as your dynamic rendering produces similar content, Googlebot won’t view dynamic rendering as cloaking,” while “serving completely different content to users and crawlers can be considered cloaking.” Same logic applies to dynamic serving: substantially-the-same content served per device is fine; a misconfiguration that looks like cloaking is the real danger.

Dynamic serving vs. dynamic rendering — don’t confuse these

This is the single clearest thing most competing content gets wrong, so it’s worth a hard line:

• Dynamic serving = device variance. Same URL, different HTML for mobile vs. desktop. The topic of this page. Google folded its guidance into the mobile-first indexingStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. doc.
• Dynamic rendering = JS-rendering variance for bots. Serving a pre-rendered/ server-rendered version of a JavaScript-heavy page to crawlers while users get the client-rendered version. It has its own dedicated, still-live Google doc, and Bing covers it in its 2018 bingbot post (“Dynamic rendering is about detecting user agent and rendering content differently for humans and search engine crawlers” — note: that’s about JS rendering for bingbotBingbot is Microsoft Bing's primary web crawler — the bot that discovers, fetches, and renders pages to build the Bing index. That index also powers Yahoo, DuckDuckGo, Ecosia, and Microsoft Copilot, so Bingbot's reach is far wider than Bing's own search-market share., not device-based serving).

They’re easy to conflate because both use user-agent detection and both raise the cloaking question — but they’re different problems with different docs.

User-agent detection is genuinely error-prone

Google’s archived guidance listed the common failure modes, and they still hold: user-agent lists need constant maintenance and won’t match brand-new agents; it’s easy to mismatch — “sometimes detecting a desktop user agent as a mobile one or detecting a mobile user agent as a desktop”; and a specific classic, “a common mistake for sites is to inadvertently treat tablet devices as smartphones.” Google’s own summary — “Use the Vary HTTP header to signal your changes depending on the user agent. Detect user agent strings correctly.” — sounds simple but is the whole maintenance burden in two sentences.

Google has fielded these mistakes for a decade. Back in January 2015, Pierre Far of Google flagged the top implementation problems he saw — around handling JavaScript, CSS, and image variants correctly across devices, not just the Vary header — a reminder that “add the header” was never the whole story.

Why responsive design is now the default

Two forces made dynamic serving a legacy pattern. First, Google has recommended responsive design “because it’s the easiest design pattern to implement and maintain” since at least 2015 — one version, no device-detection risk at all. Second, mobile-first indexingGoogle's practice of using the mobile version of a page's content — crawled by Googlebot smartphone — for indexing and ranking. It is not a separate index and not a ranking boost. completed in 2023–2024, which raised the stakes of getting device serving wrong: the mobile version is now the version Google primarily crawls, indexes, and ranks, so a dynamic-serving misconfiguration doesn’t just serve Googlebot a bad mobile page — it serves Googlebot your primary indexed content, wrong. The same push away from device-specific setups that applies to separate m-dot URLsGoogle's practice of using the mobile version of a page's content — crawled by Googlebot smartphone — for indexing and ranking. It is not a separate index and not a ranking boost. applies to dynamic serving too: consolidate to one responsive URL and the whole class of problems disappears.

For the full mobile picture — content parity, Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. on mobile, usability, interstitialsIn SEO, interstitials are full-page popups or overlays that block the main content of a page. Google demotes pages with intrusive interstitials shown on the transition from a search click — a page-level signal, with legal gates, login walls, and small dismissible banners exempted., and where AMPAMP (Accelerated Mobile Pages) is an open-source web framework Google launched in 2015 to make mobile pages load near-instantly via restricted HTML/CSS/JS and CDN caching. It was never a ranking factor and, since June 2021, is no longer required for Top Stories. stands — see the mobile SEOMobile SEO is the practice of optimizing a site so it ranks well when crawled and indexed by a mobile (smartphone) user agent and delivers a fast, usable experience on phones. Since Google completed mobile-first indexing, the mobile version is the primary version Google uses for indexing and ranking — so mobile SEO is effectively baseline SEO for every site. hub and the mobile SEO checklist.

How to check if a site uses dynamic serving

Concrete and fast: request the same URL twice with different user-agent strings and compare. If the HTML differs and the response carries Vary: User-Agent, it’s dynamic serving. If the HTML is identical (and it just re-flows via CSS), it’s responsive. The Scripts tab has curl, DevTools, and bookmarklet versions. The tell to watch for: HTML that differs by device but no Vary header — that’s the misconfiguration that risks caches and crawlers seeing the wrong version.

AI summary

A condensed take on the Advanced version:

• Dynamic servingA mobile configuration where the server returns different HTML/CSS from the same URL depending on the requesting user-agent (desktop vs. mobile), signaled with the Vary: User-Agent header. = same URL, different HTML/CSS per user-agentA user agent is the HTTP request header a client (browser, crawler, or bot) sends to identify itself. For crawlers, a short user-agent token — a substring of that string — is what robots.txt rules actually target. (desktop vs. mobile vs. tablet), detected server-side and signaled with the Vary: User-Agent response header.
• One of three mobile configs: responsive designA mobile configuration that serves the same HTML on the same URL to every device and uses CSS media queries to adapt the layout to the viewport. It's Google's recommended setup and requires a correct viewport meta tag to work. (same URL + same HTML, CSS media queries — Google’s recommendation), dynamic serving (same URL, different HTML), and separate URLs / m-dot (different URL + different HTML). Two of the three depend on Vary.
• The Vary: User-Agent header does two jobs: (1) stops caches (browsers, CDNs, ISPs) serving a mobile visitor the cached desktop page or vice versa, and (2) historically helped GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer. discover the mobile version. Most competitor content mentions only the first.
• It has a real cost: Vary: User-Agent fragments CDN cache keys across every distinct UA string (every browser/OS/botA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index.), multiplying origin requests (SiteGround estimates 5–30×). A major, under-discussed reason sites moved off it.
• Cloaking risk is about outcome, not the technique. Serving device-appropriate content is fine; the danger is a detection bug/missing Vary serving GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer. the wrong version, or deliberately serving crawlersA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. different content. Never special-case “Googlebot” in detection — treat its declared device like any device.
• User-agent detection is error-prone: stale UA lists, desktop-as-mobile mismatches, and treating tablets as phones.
• Not the same as dynamic renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM. (pre-renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM. JS for bots) — different concept, different Google/Bing docs.
• Legacy pattern in 2026. Google has recommended responsive since ~2015, and mobile-first indexingGoogle's practice of using the mobile version of a page's content — crawled by Googlebot smartphone — for indexing and ranking. It is not a separate index and not a ranking boost. (complete 2023–2024) raised the stakes of a dynamic-serving misconfiguration. Mostly something you audit an older/enterprise site off of.
• To detect it: request the same URL with a desktop vs. mobile UA, compare the HTML, and check for the Vary: User-Agent header.

Official documentation

Primary-source documentation from the search engines.

Google

• Mobile-first Indexing Best Practices — where the dynamic servingA mobile configuration where the server returns different HTML/CSS from the same URL depending on the requesting user-agent (desktop vs. mobile), signaled with the Vary: User-Agent header. and separate-URLs definitions now live (the dedicated dynamic-serving page was folded in here) and where Google states the responsive-design recommendation.
• Dynamic Serving (original dedicated doc — archived) — the retired, much richer page (last updated Jan 2021). This is the source for the “two jobs of the Vary header” explanation and the user-agentA user agent is the HTTP request header a client (browser, crawler, or bot) sends to identify itself. For crawlers, a short user-agent token — a substring of that string — is what robots.txt rules actually target.-detection failure modes. The live URL now 301-redirectsA redirect sends browsers and crawlers from a requested URL to a different one. An HTTP redirect specifically is a 3xx status code paired with a Location header; meta refresh and JavaScript redirects achieve a similar navigation without being a 3xx response themselves. Permanent redirects (301/308) are Google's signal the target should be canonical; temporary ones (302/303/307) aren't. to the mobile-first indexingGoogle's practice of using the mobile version of a page's content — crawled by Googlebot smartphone — for indexing and ranking. It is not a separate index and not a ranking boost. guide, which dropped most of this detail.
• Dynamic Rendering as a workaround — the related-but-distinct JS-renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM. concept, with the “not cloaking if the content is similar” clarification. Cited here only to draw the distinction.
• Announcing mobile-first indexing for the whole web (Mar 2020) — context on why device serving matters more today.

Bing / Microsoft

• bingbot Series: JavaScript, Dynamic Rendering, and Cloaking. Oh My! (Oct 2018) — Bing’s guidance on dynamic renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM. (JS-for-botsA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index.), not device-based dynamic serving. Bing does not appear to publish a dedicated device-based dynamic-serving/Vary doc the way Google historically did; it broadly favors responsive/single-URL setups.

Quotes from the source

On-the-record statements from Google and the industry. Live Google-doc links are deep links that jump to the quoted passage; archived and relayed sources are noted.

Google — the definition and the recommendation (live doc)

• “Dynamic servingA mobile configuration where the server returns different HTML/CSS from the same URL depending on the requesting user-agent (desktop vs. mobile), signaled with the Vary: User-Agent header.: Uses the same URL regardless of device. This configuration relies on user-agentA user agent is the HTTP request header a client (browser, crawler, or bot) sends to identify itself. For crawlers, a short user-agent token — a substring of that string — is what robots.txt rules actually target. sniffing and the Vary: user-agent HTTP response header to serve a different version of the HTML to different devices.” — Google Search Central docs. Jump to quote
• “Separate URLs: Serves different HTML to each device, and on separate URLs. Like dynamic serving, this configuration relies on the user-agent and Vary HTTP headers to redirectA redirect sends browsers and crawlers from a requested URL to a different one. An HTTP redirect specifically is a 3xx status code paired with a Location header; meta refresh and JavaScript redirects achieve a similar navigation without being a 3xx response themselves. Permanent redirects (301/308) are Google's signal the target should be canonical; temporary ones (302/303/307) aren't. users to the device-appropriate version of the site.” Jump to quote
• “Google recommends Responsive Web DesignA mobile configuration that serves the same HTML on the same URL to every device and uses CSS media queries to adapt the layout to the viewport. It's Google's recommended setup and requires a correct viewport meta tag to work. because it’s the easiest design pattern to implement and maintain.” Jump to quote

Google — the Vary header’s two jobs (archived dedicated doc, last updated Jan 2021)

• “The Vary HTTP header has two important and useful implications: It signals to cachingCaching stores a copy of a page or resource — in a browser, a CDN edge node, or a search crawler's own cache — so it can be served again without regenerating or re-downloading it. It isn't a direct ranking factor, but it feeds page speed and crawl efficiency. servers used in ISPs and elsewhere that they should consider the user agentA user agent is the HTTP request header a client (browser, crawler, or bot) sends to identify itself. For crawlers, a short user-agent token — a substring of that string — is what robots.txt rules actually target. when deciding whether to serve the page from cache or not. Without the Vary HTTP header, a cache may mistakenly serve mobile users the cache of the desktop HTML page or vice versa. It helps GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer. discover your mobile-optimized content faster.” — Google Search Central, Dynamic Serving (archived).
• “Be very careful of cloaking when detecting user agents… it should not be looking specifically for GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer.. All Googlebot user agents identify themselves as specific mobile devices, and you should treat these Googlebot user agents exactly like you would treat these devices.” — Google Search Central, Dynamic Serving (archived).

Google — dynamic renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM. (the distinct concept) (live doc)

• “As long as your dynamic renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM. produces similar content, Googlebot won’t view dynamic rendering as cloaking.” Jump to quote

SiteGround — the CDN cost of Vary: User-Agent (industry)

• “With the User-Agent [header] enabled, the system will keep different copies for each combination of OS and browser version visiting your site… you will have 5-30 dynamic requests for the same 100 visits. So the very same site will use 5-30 times the resources.” — SiteGround, “How the Vary HTTP Header Can Be Bad.”

Which mobile configuration should I use?

Almost everyone should land on responsive designA mobile configuration that serves the same HTML on the same URL to every device and uses CSS media queries to adapt the layout to the viewport. It's Google's recommended setup and requires a correct viewport meta tag to work. — but this walks the real decision, including the cases where dynamic servingA mobile configuration where the server returns different HTML/CSS from the same URL depending on the requesting user-agent (desktop vs. mobile), signaled with the Vary: User-Agent header. or separate URLs get considered, and what to do if you’ve inherited one.

The short version: responsive is the answer for almost every case. Dynamic serving and m-dot are things you manage down on sites that already have them, not patterns to reach for new.

Dynamic serving audit checklist

• Request the same URL with representative desktop and mobile user agentsA user agent is the HTTP request header a client (browser, crawler, or bot) sends to identify itself. For crawlers, a short user-agent token — a substring of that string — is what robots.txt rules actually target. and confirm whether the HTML intentionally differs.
• Send Vary: User-Agent on every response whose representation changes by device class, including cached and error responses where applicable.
• Keep primary copy, headings, internal linksAn internal link is a hyperlink from one page on a website to another page on the same website. Internal links help search engines discover your pages and pass ranking signals (PageRank and anchor-text context) between them., images and alt textAlt text is the value of the `alt` attribute on an HTML `<img>` element — a short text substitute chosen for the image's purpose and context, not a literal description of what it shows. It makes images accessible to screen-reader users and helps search engines understand images, mainly for image search., metadata, robots directives, and structured dataStructured data is a standardized way of labeling page content (using the schema.org vocabulary in JSON-LD, Microdata, or RDFa) so search engines can understand its meaning. It's not a direct ranking factor — its value is rich results and entity understanding. equivalent across versions.
• Test Googlebot SmartphoneGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer. receives the same mobile representation as a normal mobile browser; never special-case the crawlerA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index..
• Check CDN cache keys and hit behavior so one device class cannot receive the other’s cached document.
• Repeat each request several times through the CDN/cache edge (not just a single origin fetch) across desktop, mobile, tablet, and bot user agentsA user agent is the HTTP request header a client (browser, crawler, or bot) sends to identify itself. For crawlers, a short user-agent token — a substring of that string — is what robots.txt rules actually target. — a cache-poisoning failure only shows up once a variant is warmed and re-requested, not on the first fetch.
• Include tablets, unfamiliar user agents, and missing user-agent headers in the fallback test matrix.
• Remove Vary: User-Agent when the site has become genuinely responsive and the response no longer changes.
• Keep a documented migration path toward responsive designA mobile configuration that serves the same HTML on the same URL to every device and uses CSS media queries to adapt the layout to the viewport. It's Google's recommended setup and requires a correct viewport meta tag to work. where dynamic servingA mobile configuration where the server returns different HTML/CSS from the same URL depending on the requesting user-agent (desktop vs. mobile), signaled with the Vary: User-Agent header. is legacy rather than a requirement.

Dynamic serving — cheat sheet

Definition: same URL, different HTML/CSS per user-agentA user agent is the HTTP request header a client (browser, crawler, or bot) sends to identify itself. For crawlers, a short user-agent token — a substring of that string — is what robots.txt rules actually target., signaled with Vary: User-Agent.

The three mobile configs

The Vary: User-Agent header — two jobs

1. Cache correctness — stops browsers/CDNs/ISPs serving the wrong device’s cached version.
2. Crawl discovery — historically helped GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer. find the mobile version.

What it looks like

HTTP/1.1 200 OK
Vary: User-Agent

The hidden cost

• Vary: User-Agent fragments CDN cache keys across every UA string (every browser/OS/botA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index.).
• SiteGround estimate: 5–30× the origin requests for the same traffic.
• If your HTML is actually identical per device → the header is a leftover misconfiguration; remove it.

Cloaking rule

• Serving device-appropriate content = fine.
• Detection bug / missing Vary serving GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer. the wrong version = the real risk.
• Never special-case “Googlebot” in detection — treat its declared device like any device.

Common detection failures

• Stale user-agent string lists (miss new devices).
• Desktop read as mobile or vice versa.
• Tablets treated as smartphones (classic).

Don’t confuse with: dynamic renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM. = pre-renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM. JS for bots (different concept, different doc).

2026 reality: legacy pattern. Google has recommended responsive since ~2015; mobile-first indexingGoogle's practice of using the mobile version of a page's content — crawled by Googlebot smartphone — for indexing and ranking. It is not a separate index and not a ranking boost. (complete 2023–2024) raised the stakes. Audit off it; don’t build fresh.

Detect dynamic serving on any URL

The core test: request the same URL with a desktop and a mobile user-agentA user agent is the HTTP request header a client (browser, crawler, or bot) sends to identify itself. For crawlers, a short user-agent token — a substring of that string — is what robots.txt rules actually target., compare the HTML, and check for the Vary: User-Agent header. If the HTML differs, it’s dynamic servingA mobile configuration where the server returns different HTML/CSS from the same URL depending on the requesting user-agent (desktop vs. mobile), signaled with the Vary: User-Agent header. (or m-dot, if the URL changes); if the response varies but there’s no Vary header, that’s the misconfiguration to flag.

curl — compare desktop vs. mobile responses (macOS / Linux)

URL="https://example.com/"
DESKTOP="Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/125.0 Safari/537.36"
MOBILE="Mozilla/5.0 (Linux; Android 14; Pixel 8) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/125.0 Mobile Safari/537.36"

# Fetch both, hash the body — different hashes = different HTML per device
curl -sA "$DESKTOP" "$URL" | shasum
curl -sA "$MOBILE"  "$URL" | shasum

# Is the site even sending Vary: User-Agent? (headers only)
curl -sI "$URL" | grep -i '^vary:'

curl — impersonate Googlebot smartphoneGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer. (verify what the crawlerA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. gets)

GBOT="Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/W.X.Y.Z Mobile Safari/537.36 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
curl -sA "$GBOT" "https://example.com/" | shasum
# Compare to the $MOBILE hash above — they should match. If Googlebot gets the
# desktop version, that's the misconfiguration that can look like cloaking.

Windows (PowerShell) — same comparison

$Url = "https://example.com/"
$Desktop = "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/125.0 Safari/537.36"
$Mobile  = "Mozilla/5.0 (Linux; Android 14; Pixel 8) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/125.0 Mobile Safari/537.36"

(Invoke-WebRequest $Url -UserAgent $Desktop).RawContentLength
(Invoke-WebRequest $Url -UserAgent $Mobile ).RawContentLength
(Invoke-WebRequest $Url -Method Head).Headers["Vary"]

Chrome DevTools — no terminal needed

1. Open DevTools (F12 / Cmd+Opt+I), open the Network conditions tab (⋮ → More tools → Network conditions).
2. Uncheck “Use browser default,” pick a mobile UA (or paste GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer.’s smartphone string), and reload. Compare the rendered page and, in the Network panel, the document request’s Response Headers for Vary.
3. Toggle back to a desktop UA and reload — different HTML on the same URL is your tell.

Browser-console snippet — check the current page’s Vary header

// Paste in the DevTools Console on the page you're testing
fetch(location.href, { method: "HEAD", cache: "no-store" })
  .then(r => console.log("Vary:", r.headers.get("vary") || "(none)"));

Bookmarklet — one-click Vary check

javascript:(async()=>{const r=await fetch(location.href,{method:"HEAD",cache:"no-store"});alert("Vary: "+(r.headers.get("vary")||"(none set)"));})();

Note: fetch only exposes response headers the server allows via CORS for cross-origin requests, so the console/bookmarklet checks are most reliable on the same origin you’re viewing. For a definitive header read, use curl -I or the DevTools Network panel.

Tools for auditing device-dependent responses

• curl: Repeat the same request with explicit desktop, mobile, and GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer. Smartphone user agentsA user agent is the HTTP request header a client (browser, crawler, or bot) sends to identify itself. For crawlers, a short user-agent token — a substring of that string — is what robots.txt rules actually target.; compare headers, status, body size, and content hashes.
• Chrome DevTools Network panel: Override the user agentA user agent is the HTTP request header a client (browser, crawler, or bot) sends to identify itself. For crawlers, a short user-agent token — a substring of that string — is what robots.txt rules actually target., disable cache, and inspect the actual document response rather than assuming device emulation changes it.
• Search ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results. URL InspectionA Google Search Console feature that reports how Google sees one specific URL on a property you own. By default it shows the last-indexed snapshot; a separate \"Test live URL\" mode fetches the current version.: Check the rendered HTML GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer. Smartphone received for representative URLs.
• A crawlerA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. with user-agent configuration: Run separate mobile and desktop crawls, then diff titles, headings, canonicals, directives, structured dataStructured data is a standardized way of labeling page content (using the schema.org vocabulary in JSON-LD, Microdata, or RDFa) so search engines can understand its meaning. It's not a direct ranking factor — its value is rich results and entity understanding., and internal links at scale.
• CDN cache analytics: Segment hits, misses, and cache keys by device class to find cache fragmentation or cross-device leakage.

Dynamic serving anti-patterns

The failure modes that turn dynamic servingA mobile configuration where the server returns different HTML/CSS from the same URL depending on the requesting user-agent (desktop vs. mobile), signaled with the Vary: User-Agent header. from “works” into “actively hurting you”:

1. Serving different HTML with no Vary: User-Agent header. The cardinal sin. Without it, a cache can store the desktop version and hand it to a phone (or hand Googlebot smartphoneGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer. the desktop page). The content varies but nothing tells caches or crawlersA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. that — so the wrong version leaks. If you serve per-device HTML, the header is non-negotiable.

2. Adding Vary: User-Agent on a site that’s actually responsive. The opposite mistake, and a common one. If your HTML is identical across devices, the header does nothing useful and fragments your CDN cache across every user-agentA user agent is the HTTP request header a client (browser, crawler, or bot) sends to identify itself. For crawlers, a short user-agent token — a substring of that string — is what robots.txt rules actually target. string (SiteGround: 5–30× the requests). Don’t add it “to be thorough” — only when you genuinely serve different HTML per device.

3. Special-casing “GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer.” in detection logic. Detecting the device class is fine; sniffing specifically for Googlebot and serving it something different is how accidental cloaking happens. Googlebot announces itself as a specific mobile device — treat it exactly like that device.

4. Letting desktop and mobile HTML drift out of parity. Two versions means two things to keep in sync. Under mobile-first indexingGoogle's practice of using the mobile version of a page's content — crawled by Googlebot smartphone — for indexing and ranking. It is not a separate index and not a ranking boost., the mobile version is what’s indexedStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. — so content, structured dataStructured data is a standardized way of labeling page content (using the schema.org vocabulary in JSON-LD, Microdata, or RDFa) so search engines can understand its meaning. It's not a direct ranking factor — its value is rich results and entity understanding., images/alt textAlt text is the value of the `alt` attribute on an HTML `<img>` element — a short text substitute chosen for the image's purpose and context, not a literal description of what it shows. It makes images accessible to screen-reader users and helps search engines understand images, mainly for image search., and links that exist only on desktop are, for indexingStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. purposes, gone.

5. Stale user-agent lists and tablet-as-phone mismatches. UA-detection lists rot: new devices go unmatched, desktops get read as mobile, and tablets get treated as smartphones. Detection you set up once and never revisit will quietly misclassify a growing slice of traffic.

6. Treating dynamic serving as a fresh “option” to pick. It’s not one of three co-equal choices in 2026. Google has recommended responsive since ~2015, and mobile-first indexingGoogle's practice of using the mobile version of a page's content — crawled by Googlebot smartphone — for indexing and ranking. It is not a separate index and not a ranking boost. raised the stakes. If you’re choosing new, choose responsive; dynamic serving is legacy debt to manage down.

7. Confusing it with dynamic renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM.. Reaching for JS pre-renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM. docs (or Bing’s bingbotBingbot is Microsoft Bing's primary web crawler — the bot that discovers, fetches, and renders pages to build the Bing index. That index also powers Yahoo, DuckDuckGo, Ecosia, and Microsoft Copilot, so Bingbot's reach is far wider than Bing's own search-market share. post) to configure device-based serving. Different problem, different solution — mixing them produces guidance that fits neither.

Common dynamic serving failures

Mobile users intermittently receive the desktop page

Symptom: The correct mobile response appears on a cold request but desktop HTML appears after cache hits. Likely cause: The response varies by user agentA user agent is the HTTP request header a client (browser, crawler, or bot) sends to identify itself. For crawlers, a short user-agent token — a substring of that string — is what robots.txt rules actually target. without a matching cache key or Vary: User-Agent. Fix: Correct the origin header and CDN configuration, purge affected objects, then repeat cross-device requests against warm cache entries.

Googlebot Smartphone sees less content

Symptom: URL InspectionA Google Search Console feature that reports how Google sees one specific URL on a property you own. By default it shows the last-indexed snapshot; a separate \"Test live URL\" mode fetches the current version. lacks copy, links, structured dataStructured data is a standardized way of labeling page content (using the schema.org vocabulary in JSON-LD, Microdata, or RDFa) so search engines can understand its meaning. It's not a direct ranking factor — its value is rich results and entity understanding., or images available on desktop. Likely cause: Mobile templates have drifted or device detection routed GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer. incorrectly. Fix: Restore parity from the shared content source and test the exact smartphone crawlerA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. agent alongside a normal phone agent.

A responsive site has poor cache efficiency

Symptom: HTML is identical across devices but the CDN stores many user-agent variants. Likely cause: A legacy Vary: User-Agent header survived the migration to responsive designA mobile configuration that serves the same HTML on the same URL to every device and uses CSS media queries to adapt the layout to the viewport. It's Google's recommended setup and requires a correct viewport meta tag to work.. Fix: Verify the response truly no longer changes, remove the header, purge variants, and confirm the cache consolidates.

Validate a dynamic serving change

Test representation and header agreement

Test to run: Request the same URL with desktop and mobile user agentsA user agent is the HTTP request header a client (browser, crawler, or bot) sends to identify itself. For crawlers, a short user-agent token — a substring of that string — is what robots.txt rules actually target. and record body hashes plus the Vary header. Expected result: Intentionally different bodies both declare Vary: User-Agent; identical responsive bodies do not carry a needless device variance. Failure interpretation: Cache signaling and origin behavior disagree. Monitoring window: Immediate. Rollback trigger: Different bodies can share one unvaried cache object.

Test warmed-cache isolation

Test to run: Warm the URL with one device class, then request it as the other in both orders. Expected result: Each receives its intended representation every time. Failure interpretation: The CDN cache key ignores the device variation. Monitoring window: Immediate after CDN or header changes. Rollback trigger: A mobile request receives desktop HTML or vice versa.

Test mobile content parity

Test to run: Diff a sample of desktop and mobile rendered output for primary content, metadata, directives, links, and structured dataStructured data is a standardized way of labeling page content (using the schema.org vocabulary in JSON-LD, Microdata, or RDFa) so search engines can understand its meaning. It's not a direct ranking factor — its value is rich results and entity understanding.. Expected result: Layout may differ, but indexable meaning and signals remain equivalent. Failure interpretation: Template drift changes what mobile-first indexingGoogle's practice of using the mobile version of a page's content — crawled by Googlebot smartphone — for indexing and ranking. It is not a separate index and not a ranking boost. can use. Monitoring window: On release and after recrawlCrawl frequency is how often a search engine comes back to re-fetch a page it already knows about. Popular pages that change often get refreshed many times a day; stable pages can go weeks or months between crawls — and you influence it indirectly, not by setting a dial. in URL InspectionA Google Search Console feature that reports how Google sees one specific URL on a property you own. By default it shows the last-indexed snapshot; a separate \"Test live URL\" mode fetches the current version.. Rollback trigger: The mobile representation drops an indexable element or adds a restrictive directive.

Test yourself: Dynamic Serving

Five quick questions on dynamic servingA mobile configuration where the server returns different HTML/CSS from the same URL depending on the requesting user-agent (desktop vs. mobile), signaled with the Vary: User-Agent header. and the Vary header. Pick an answer for each, then check.

Resources worth your time

My related writing

• The Beginner’s Guide to Technical SEO — where mobile configuration and crawl/indexStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. fit the bigger picture.
• JavaScript SEO Issues & Best Practices — relevant for the dynamic renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM. concept people confuse with dynamic servingA mobile configuration where the server returns different HTML/CSS from the same URL depending on the requesting user-agent (desktop vs. mobile), signaled with the Vary: User-Agent header. (the JS-for-botsA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. side, not device serving).

My speaking

• How Search Works (SlideShare) — my walkthrough of crawlingCrawling is how search engines use automated bots (like Googlebot and Bingbot) to discover URLs and download pages. A page has to be crawlable to be indexed, but crawling on its own isn't a ranking factor., renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM., indexingStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed., and ranking, including how GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer. crawls as a smartphone (which is why device-serving misconfigurations bite under mobile-first indexingGoogle's practice of using the mobile version of a page's content — crawled by Googlebot smartphone — for indexing and ranking. It is not a separate index and not a ranking boost.). (Standing disclaimer: “This is my understanding of systems… not going to be 100% complete or accurate.”)

From around the industry

• Mobile-first Indexing Best Practices (Google) — the current home of the dynamic serving and separate-URLs definitions and the responsive-design recommendation.
• Dynamic Serving (archived original Google doc) (Google, via Wayback Machine) — the retired, more detailed page with the two-jobs-of-Vary explanation and the user-agentA user agent is the HTTP request header a client (browser, crawler, or bot) sends to identify itself. For crawlers, a short user-agent token — a substring of that string — is what robots.txt rules actually target.-detection failure modes.
• Dynamic rendering as a workaround (Google) — the distinct JS-rendering concept, with the “similar content isn’t cloaking” clarification.
• Mobile Site Configuration & The Vary HTTP Header (Search Engine Land, Cindy Krum, 2013) — the enterprise CDN vs. Vary header conflict. Dated, but the underlying cache-fragmentation tension still holds.
• How the Vary HTTP Header Can Be Bad (SiteGround) — the plain-terms breakdown of Vary: User-Agent cache fragmentation and the 5–30× resource-cost estimate.
• Google’s Top Three Problems They See With Dynamic Serving Mobile Sites (Search Engine Roundtable, 2015) — Pierre Far’s flagged JS/CSS/image implementation mistakes, an early “even Google was fielding this” record.

Dynamic Serving

A mobile configuration where the server returns different HTML/CSS from the same URL depending on the requesting user-agent (desktop vs. mobile), signaled with the Vary: User-Agent header.

Related: Mobile-First Indexing, Responsive Web Design

Dynamic Serving

Dynamic serving is a mobile-configuration technique where a website uses the same URL for every device, but the server inspects the requesting user-agentA user agent is the HTTP request header a client (browser, crawler, or bot) sends to identify itself. For crawlers, a short user-agent token — a substring of that string — is what robots.txt rules actually target. and returns different HTML (and CSS) depending on whether the visitor is on desktop, mobile, or tablet. Because the HTML varies by device while the URL stays fixed, the server must send the Vary: User-Agent HTTP response header on every dynamically-served response, so caches (browsers, CDNs, proxies) and search engines know the content varies by user-agent and don’t serve a cached copy of the wrong version to the wrong visitor.

It sits alongside two other mobile configurations: responsive designA mobile configuration that serves the same HTML on the same URL to every device and uses CSS media queries to adapt the layout to the viewport. It's Google's recommended setup and requires a correct viewport meta tag to work. (same URL, same HTML/CSS everywhere, layout adapts via CSS media queries — Google’s recommended option) and separate URLs (different HTML and a different URL per device, e.g. m.example.com).

Google has consistently recommended responsive design over dynamic serving because dynamic serving depends on correct, ongoing user-agent detection and correct Vary configuration — get either wrong and Google (or a cache) can see or serve the wrong version, which can look like cloaking even when unintentional. Don’t confuse it with dynamic renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM., which is about serving a pre-rendered version of a JavaScript-heavy page to crawlersA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. — a different concept with a different Google doc.

Related: Mobile-First Indexing, Responsive Web Design

Changelog