Target Proxies: 2,163 Words Need the Browser

Target proxies are the one case in this series where the browser earns its bill. On 26 September 2026 target.com gave a plain HTTP client behind a United States residential exit 317 words; a headless browser got 2,163, 6.8 times more, the exact opposite of Best Buy, which sells the same categories and renders into one word fewer. On 28 September the plain fetch weighed 416,892 bytes and the rendered one 1,905,846, so the browser buys 6.8 times the words for 4.6 times the bytes. The exit country changes nothing in the page, a British exit got the same 256 words as an American one, but the page state assigns every visitor a store and a ZIP from the IP alone, and that assignment is what a Target proxy actually selects.

The render multiplies Target by 6.8, the opposite of Best Buy

We audited the home with the tool in our MCP server, which fetches once as a pure HTTP bot and once fully rendered and counts the words in each view, then weighed both fetches two days later.

The plain page is not empty, and that matters for how you classify it. It has the title "Target : Expect More. Pay Less.", a canonical of https://www.target.com/, an h1 that literally reads "Homepage", a WebPage JSON-LD block and a robots tag of index, follow. It is a Next.js application shell with the navigation and the section headings server-rendered and every product tile left for the client. Best Buy ships the same kind of shell and then adds nothing in the browser; Target ships the shell and then adds 1,846 words of merchandising, deals and category rails. Two retailers, one category, and the measurement points in opposite directions. That is the reason a page per target exists: the network is the same residential exit in both cases, and the right fetch mode is decided by the site, not by the proxy.

Read the bytes column with the words column. The browser costs 4.6 times the bytes and 2.3 times the seconds to deliver 6.8 times the words, so on Target the render is the cheaper way to get a word, at 881 bytes per word against 1,315 for the plain fetch. That arithmetic only holds because the words you want are the ones JavaScript loads; on Walmart the render costs 7.5 times the bytes for 1.4 times the words and the arithmetic goes the other way.

The same 256 words from London and from Chicago, and a store nobody chose

Row five is the geo result, and it is a null one: a United Kingdom residential exit got the same 256-word page as the United States exit, same title, same canonical, same JSON-LD. Target does not localise its front door by country and does not redirect a foreign visitor anywhere. For a country-level job, that means the exit is not a lever.

The lever is one level down, and it is visible in the page without executing it. Target's server-rendered state carries the visitor's assignment: our fetch from a US exit was given store_id: 3991 and a nearby-stores query for place: 61486, a ZIP code, before any cookie existed and before any script ran. The same state carries isBot: false and is_seo_bot: false, which is Target telling you how it classified your client. Nothing in our request said where we were; the exit IP did, and Target turned it into a store. On product pages, that store decides the price shown, the pickup availability and the delivery promise. So a Target proxy is not a country selector, it is a store selector, and a rotating pool that drifts across ZIPs mid-crawl produces rows whose price belongs to one store and whose availability belongs to another. Hold a sticky exit while a crawl is scoped to a store, and write the store id from the page state into every row, because it is the only honest key for the price you captured.

Rendering through the API costs half of rendering through the pipe

Prices from our pricing page: residential Basic $0.80/GB, and the web scraping API from $0.0002 per page, or $0.001 with rendering. A gigabyte here is 10^9 bytes.

The row to read is the last one against the second. Rendering Target through raw residential bandwidth costs $1.52 per thousand pages at 1.9 MB a page; rendering it through the API costs $1.00, because the API bills per page and not per byte, and a 1.9 MB page is exactly the kind of page that per-byte pricing punishes. On Target, the setting is rendered, and the cheaper way to render is the API. Per word, the rendered API page costs $0.00046 per thousand words and the plain one $0.00063: the browser is the bargain here, which it is on none of the other five retailers in this series.

There is no Target collector in our catalogue. For a cross-retailer price check on the same product, product_offers returns every seller offer for a product at $0.002 per delivered offer, and google_shopping returns priced listings per query. For the Target page itself, the web scraping API with rendering is the job, and if the page you need is a product page, hold the store.

Target's robots.txt closes search and names no AI bot

target.com/robots.txt is 3,226 bytes, last modified on 8 July 2026. Six gzipped sitemap indexes come first: keywords, stores, taxonomy categories, product pages, brands and facet categories. The wildcard rules then close search (/s?), product lists under /pl/, /shop/, the cart, accounts, tracking and review submission, and carry a long tail of legacy paths from earlier platforms. No AI crawler is named and there is no Allow line: the file is a plain exclusion list and product pages under /p/ are not in it.

The Terms & Conditions page is the honest example of what a raw client sees on this site: fetched over plain HTTP it returned 200 and 130 words, all of them navigation and footer, because the terms themselves are loaded by the same client-side orchestration as the products. The seller portal, Target Plus, is more direct: it returns one sentence telling you to enable JavaScript. Target runs a marketplace for approved sellers with its own partner tooling, and that, not a public catalogue API, is the licensed route to Target data. Three of the ten pages ranking for this keyword are about restock monitoring and automated checkout for collectible card drops; we do not help with automated purchasing, and a proxy does not change how a retailer treats a bot at checkout, because that decision is made on behaviour, not on the address.

The setting that works on Target

• Network: residential, Basic line at $0.80/GB, sticky while a crawl is scoped to a store. Every fetch in this post went through it, one attempt each.
• Fetch mode: rendered. 2,163 words rendered against 317 without JavaScript on 26 September, 6.8 times more, at 1,905,846 bytes against 416,892.
• Country: country: "us", and expect no change from any other: a United Kingdom exit got the same 256 words. What the exit does change is the store Target assigns; ours was store 3991 for ZIP 61486, from the IP alone. Pin the exit near the store whose prices you want and hold it.
• When the proxy is not enough: the web scraping API with rendering at $0.001 per page, which is $1.00 per thousand against $1.52 for the same render over raw bandwidth. For offers across retailers, product_offers at $0.002 per delivered offer.
• Free tier: every account gets $2 of free API usage per month, which is 2,000 rendered Target pages.