Proxies for Home Depot put a clean US residential address in front of each request, so homedepot.com sees shoppers in the towns whose stores you want to read instead of one server pulling every store's price list. Home Depot is a per-store pricing business. It operates more than 2,300 stores across the United States, Canada and Mexico (The Home Depot, about), and its own price-match page tells customers that local store prices may vary from those displayed on the website (Home Depot, price match and price inquiries). "The Home Depot price" of a SKU is therefore a table with one row per store, and a scraper reading it from one address gets one row, if it gets anything at all.
We tested the door on 24 August 2026: one plain GET to homedepot.com from a home broadband connection, then the same request from a datacenter server. Both came back as HTTP 403 with Akamai's Access Denied page and a reference number, before any product page had been asked for. That single result decides the proxy strategy for Home Depot. The site judges the client before it judges the address, so the IP is necessary and not sufficient, and the setup has to be built around a real browser from the start.
What proxies work best for Home Depot?
US rotating residential proxies, targeted to the region of each store you read, behind a headless browser that runs Akamai's sensor script. A static ISP proxy for any session that logs in or holds a cart. Datacenter proxies are denied on the first request, and free proxies are useful only to prove your pipeline forwards traffic.
One SKU, many prices
Home Depot localizes in two directions at once, and both matter to a data project.
Across stores, the price of an identical item can differ. The site asks you to select a store, shows price and availability for that store, and seeds its first guess from your IP address. Selection differs too: each store carries a mix shaped by local demand, climate and building codes, so a SKU that is stocked in Houston may not exist in Portland. Across channels, the online price and the in-aisle price for the same SKU at the same store are not guaranteed to match, which is why the price-match page exists in the first place. For a monitoring project this means the unit of work is a store-SKU pair, and the number of pairs is what sets your request volume.
The people who read Home Depot at this granularity are a specific crowd:
- Competing retailers. Lowe's publishes a Price Promise that matches identical items from local competitors and named online retailers, and Home Depot's own policy mirrors it; both sides watch each other's shelf prices, store by store (Lowe's Price Promise).
- Brands enforcing minimum advertised price. A tool or appliance brand with a MAP policy needs to see the advertised price at every store, because a single store running a regional promotion is a violation the brand has to notice.
- Clearance and resale hunters. Markdowns happen per store, so the money is in scanning many stores for the same SKU, which is the most detectable pattern in retail scraping.
- Contractors and estimators. Pro buyers price out jobs against the store they will actually pick up from, sometimes across several stores in a metro.
- Marketplace sellers and analysts. Catalog, category and review data at scale, for sourcing decisions and market sizing.
What Akamai did to a plain client
Both of our test requests got the same treatment: a 403 served by AkamaiGHost, an Access Denied page carrying a reference number, and a handful of Akamai routing cookies. No product, no sensor script, no chance to prove anything. The decision was made on the request itself, and the two things a bare client gets wrong are the TLS handshake (the JA3/JA4 signature computed from the ClientHello before any HTTP is sent) and the header set, which a real Chrome sends in a specific order with client-hint headers a script never includes (what is JA3/JA4 fingerprinting).
Past that door, Akamai Bot Manager keeps scoring. A sensor script in the page collects device and behavioral signals and posts them to Akamai; the _abck cookie only reaches a valid state after the sensor data passes, and every protected request afterwards must carry it (how the _abck cookie works). Rate limits apply per IP on top of that. The complete playbook for this vendor is in how to scrape past Akamai; the point for proxy selection is that residential and datacenter addresses both fail without the browser, and only residential addresses succeed with it.
The proxy solves
IP reputation
residential ranges pass, datacenter ranges do not
Store region
an exit near the store you read
Session isolation
one address per account or store batch
Per-IP rate limits
spread across a pool
Only the browser solves
TLS fingerprint
JA3/JA4 read before any HTTP
Header order and client hints
what got us the 403
The _abck sensor cookie
set only by the sensor script
Behavior
timing, movement, page flow
Which proxy type fits which job
| Home Depot job | Proxy type | Why |
|---|---|---|
| Store-level price and stock across many regions | US rotating residential, region-targeted | Each store needs an exit that fits it, and volume needs a pool |
| MAP monitoring for a brand's SKUs | Rotating residential | Many stores, modest rate per store |
| Clearance watch on a few stores | Sticky residential per store | Keeps one store selection through a batch |
| Pro Xtra account, cart, order history | Static ISP | The session must keep one address |
| Review and Q&A collection | Rotating residential | Separate endpoints, own limits |
| Local parser tests against saved HTML | None | The live site denies datacenter clients outright |
Rotating residential IPs are real home connections drawn from a pool, so Akamai's reputation check passes and the request rate spreads across many addresses. ISP proxies are residential-registered addresses that never change, which is what a logged-in Pro account needs. Mobile proxies are the heavyweight tier for sessions that keep getting flagged and are rarely needed for catalog work. The tradeoffs between the two residential kinds are in rotating vs static residential proxies.
Setup: choose the store before you read the price
Set the store explicitly. Do not let the site infer it from the IP, because a rotating pool will hand you a new inferred store with every exit and your dataset will silently mix stores. Select the store in the session (the site stores the choice in cookies) and keep that session on one sticky exit for the whole batch of SKUs at that store; rotate between store batches, never inside one.
Keep the exit consistent with the store. A Phoenix store read through an exit in Ohio is not wrong data on its own, but it is the combination Akamai's risk score notices, and it can flip the site back to inferring a store from the IP. Target the residential pool to the state or metro of the store you are reading. Our pool supports country and region targeting, and geo-testing with proxies shows the verification step: confirm the exit location before trusting the data.
Drive a browser and persist the cookies. Playwright or Puppeteer behind the proxy, with the profile kept across requests, so the sensor sets _abck once and the store selection survives (proxies for Playwright, proxies for Puppeteer). Discarding cookies every request restarts the sensor and reads as a bot.
Separate delivery ZIP from store. Delivery availability keys off a ZIP code, store availability keys off the store; set both, and record both in your data so a later reader knows which price they are looking at.
Sizing
Start from arithmetic, not from a plan size. Requests per pass equal stores times SKUs, so a brand watching 4,000 SKUs at 300 stores makes 1.2 million reads per pass, and a weekly pass is a very different proxy budget from a daily one. Then find the rate one residential IP tolerates before challenges appear, stay under it, and add addresses to raise throughput. With rotating residential you pay per gigabyte, and a headless browser downloads far more per page than a bare client would, a difference we measured in headless browser proxy bandwidth cost. Budget for it rather than discovering it on the invoice.
For accounts, the count is simpler: one static ISP address per Pro account, never shared, matched to the account's home region. Our pricing is pay-as-you-go with a balance that does not expire, so a large weekly pass and a quiet week in between cost what they use.
Free proxies against Home Depot
The honest answer is shorter than usual. A free proxy is a datacenter address with no browser behind it, and that exact combination got Access Denied from homedepot.com on request one in our test. Free proxies will tell you whether your code forwards traffic and whether an address is alive, and nothing more. Our free proxy list refreshes every few minutes across 100+ countries, and the proxy checker confirms an exit is up, which covers that plumbing test. For the site itself, residential from $0.44/GB pay-as-you-go with no KYC is where it starts, and when free proxies are fine draws the line for other targets.
Avoiding the Access Denied page
- Never retry a 403 on the same address. Akamai has scored that IP for the session; back off, rotate, and let the browser re-establish a sensor cookie.
- Pace per store, not per site. A human reads a few product pages at one store; spread SKU reads for one store over minutes, with jitter, and run many stores in parallel on different exits instead of one store fast.
- Keep header order and client hints intact. Use the real browser's request stack; do not rebuild headers by hand.
- Do not hammer the store-selection endpoint. Changing the store hundreds of times from one session is a pattern no shopper produces.
- Watch the challenge rate. Log the share of responses that are 403 or challenge pages. A rising share means slow down or widen the pool before the whole range is scored.
The wider request-hygiene list is in avoiding IP bans while scraping, and it applies here without changes.
What a proxy will not do
A proxy does not run Akamai's sensor, does not restore a session that changed address, and does not turn the online price into the shelf price: the in-aisle number is not on the site, and a project that needs it needs a person in the store. Scraping homedepot.com runs against Home Depot's terms of use, and that risk stays with you whatever the IPs are.
What clean, region-targeted residential exits do is make each store read look like a shopper in that store's town, which is the one thing Akamai cannot infer from the request itself. Pair them with a real browser, set the store deliberately, size from store-SKU pairs, and Home Depot becomes a large but orderly data job. The paid side starts at residential from $0.44/GB; the comparison with the retailer next door is in proxies for Lowe's.
Sources
- The Home Depot, About us: store count and countries.
- The Home Depot, Price match guarantee and price inquiries: local store prices may vary from the website.
- Lowe's, Price Promise: the competitor policy that drives cross-retailer monitoring.
- Akamai, Bot Manager: the vendor's own description of the product that served our 403.
- Cloudflare, JA3/JA4 TLS fingerprinting: how a client is fingerprinted before any HTTP is sent.
- HProxy test on 24 August 2026: one plain GET to homedepot.com from a residential connection and one from a datacenter server, both answered with HTTP 403, an Akamai Access Denied page and a reference number.