How to Capture Lazy-Loaded Product Reviews on an Ecommerce Page
Use Chrome DevTools to find the requests behind reviews that load on scroll, after a click, or through pagination—and verify what each response contains.
To capture product reviews that appear only after scrolling, clicking “Load more,” or changing review pages, open Chrome DevTools before reloading the product page. In the Network panel, record the page, trigger the review control, then inspect the new request’s response. The retailer and review widget determine how reviews load, so observe the actual request instead of guessing a universal endpoint.
This workflow helps you find review data and save or inspect the requests that deliver it. It does not promise that every site exposes reviews as readable response data: the widget may render them in another way, and access may be affected by the site’s own controls.
1. Record the review widget’s requests in Chrome
- Open the product page in Chrome, then open DevTools with Inspect or Ctrl+Shift+I on Windows/Linux or Cmd+Option+I on macOS.
- Select the Network panel before reloading. DevTools records network activity while it is open. Reloading with it open lets you see initial page requests too; opening it only after load can miss requests that already happened.
- Clear the Network log if it contains unrelated requests. Enable Preserve log if navigation or a reload could clear entries you need. You can enable Disable cache when you want to observe a first-visit request sequence without cached browser responses. Keep in mind that disabling the cache changes the conditions you are observing.
- Reload the page and wait for the product page to settle. Find the reviews section. If the page has a load-more button, pagination controls, or an infinite-scroll list, use the control the site provides.
- Compare the Network panel before and after the interaction. Start with the Fetch/XHR filter if available, but check other request types if the interaction appears to load data another way.
- Open likely requests and inspect Headers, Preview, Response, Initiator, and Timing. Look for the review text or structured review fields. Confirm that the page visibly added the same reviews.
- Trigger another batch if needed, then compare the new request with the previous one. Note which values change and whether the response contains the next reviews.
Chrome’s walkthrough demonstrates how a page interaction can trigger a new data request and how to inspect its details. The Network panel’s recording, log, and cache controls are documented in the Chrome Network features reference and Inspect network activity guide.
2. Identify how the page advances through reviews
Product review lists may show only part of a longer list. The page might append a batch, replace the visible batch, navigate to a distinct URL, or fetch data in the background while the URL stays the same. Google’s pagination guidance specifically includes product-page user reviews and describes pagination, load-more, and infinite scroll as common ways to present longer content.
For each control, record what actually happens on the target page:
| What to check | How to verify it |
|---|---|
| Does the control append or replace reviews? | Compare the visible review list before and after one interaction. |
| Does the URL change? | Watch the address bar and check whether the new state has a distinct URL. |
| Does a background request appear? | Compare the Network log around the click or scroll, then inspect likely requests. |
| Does the response contain review content? | Inspect Preview or Response and compare its records with the reviews now visible. |
| Can the same action retrieve another batch? | Repeat the interaction and observe whether another request and another visible batch appear. |
Do not assume the endpoint, parameter names, pagination scheme, or response format from another retailer. The request may contain changing values that identify a page or batch, but use only what you can observe and verify on that page.
3. Save and interpret a request
For a one-off investigation, the Network panel is usually enough to identify the request and inspect its response. If you need a record to share or analyze, use DevTools’ available request-copy or HAR export options, then treat the file as sensitive: request logs can contain URLs, headers, cookies, or other session details. Remove credentials and personal data before sharing them.
For a browser extension that uses the DevTools APIs, Chrome documents chrome.devtools.network.getHAR() and request-finished events. HAR entries do not include request content by default; use the documented request-content method when you need response bodies. The API also notes that requests made before DevTools opened may be absent, so reload with DevTools open when you need the initial sequence. See Chrome’s DevTools Network API documentation.
A HAR file is a record of browser network activity, not automatically a clean dataset of reviews. Check whether the response contains the data you need, and avoid treating incidental metadata as review content.
4. Understand the crawler distinction
A person using a live browser can scroll or click a review control. Google’s crawler generally discovers URLs through links and generally does not click buttons or invoke JavaScript functions that require a user action. As a result, reviews revealed after an interaction may not appear in the initial markup or be discoverable to a crawler in the same way. That crawler behavior does not prevent a person from inspecting the browser’s requests.
If you own the site, Google recommends making lazy-loaded content load when it enters the viewport. For infinite-scroll content, its guidance covers persistent unique URLs for chunks, stable content for a given URL, sequential links, and updating the visible URL as a new chunk becomes primary. Check rendered HTML with Search Console’s URL Inspection Tool to verify what loaded. See Google’s lazy-loading guidance and pagination and incremental page-loading guidance.
5. Troubleshooting
| Symptom | Likely cause | What to try |
|---|---|---|
| No relevant request appears | DevTools opened after the request, the wrong control was triggered, or the data loaded through a request type you did not inspect. | Open Network before reloading, clear the log, repeat the exact interaction, and inspect more than Fetch/XHR if needed. |
| The request list is noisy | Other page activity is mixed with the review interaction. | Clear the log immediately before the action, use the relevant Network filters, and compare only the entries added after the action. |
| The response does not show review text | The selected request may be unrelated, the response may be encoded or structured differently, or the visible content may be produced through another mechanism. | Check the Initiator and timing, inspect Preview as well as Response, and compare candidates with the visible review cards. Do not infer an endpoint from its name alone. |
| The page adds reviews but no new URL appears | The widget may fetch a batch in the background without changing the address bar. | Use the before-and-after Network comparison and inspect the request triggered by the interaction. |
| A reload removes useful entries | Preserve log was not enabled before navigation or reload. | Enable Preserve log and repeat the sequence. If the initial requests matter, reload after opening DevTools. |
| Repeated clicks show no next batch | The list may have reached its end, the control may be disabled, or the page may require a different interaction. | Check the visible state, try the widget’s actual pagination or scroll behavior, and verify whether a new request is made. |
| Cached activity makes the sequence hard to read | The browser reused cached resources. | When first-visit behavior is relevant, enable Disable cache in Network and reload. Record that this changes the capture conditions. |
| A HAR lacks response bodies | Chrome’s HAR data does not include request content by default. | Use the DevTools request-content API for bodies when building an extension, as described in Chrome’s Network API documentation. |
6. Reliability, performance, and responsible handling
- Repeat the observed interaction. A single request can be an initial batch, while later reviews may require further clicks or scrolls. Verify that each interaction yields the expected visible content.
- Keep the capture conditions clear. Cache settings, reload timing, and whether the page was already open can change what appears in the log.
- Prefer the browser’s observed behavior over guessed parameters. The review widget and retailer determine the request sequence and response structure.
- Limit unnecessary capture. Clear irrelevant entries and retain only the data needed for the task. Network logs may include session information.
- For site owners, validate rendered output. Use the Search Console URL Inspection Tool to check whether the content loaded as intended, rather than assuming that a visible interaction guarantees crawler discovery.
Or skip the browser setup
If you only need a clean screenshot of the product page or its review section, ScreenshotNeo is a website screenshot API and MCP server. Its capture options include full-page screenshots, a CSS selector for capturing one element, waits for a selector, delay, or network idle, and custom JavaScript or CSS. It captures a rendered image; use the DevTools workflow above when you need to inspect the underlying review response.
Install no browser automation for a one-call image capture. The API accepts a URL and returns an image or PDF. See the ScreenshotNeo API documentation.
curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp
Replace the example URL with the product page you want to capture. The same endpoint has Python and Node.js examples in the API documentation.
- Cookie and consent banners, newsletter popups, and chat widgets are removed before capture; each removal step can be turned off.
- Bot checks, blank pages, timeouts, and failed loads are never billed; cache hits are also free. Responses identify the page verdict and billing status in headers.
- An MCP server lets AI agents, including Claude and Cursor, use screenshot tools.
- The free plan includes 1,000 screenshots a month with no card. Paid plans start at $5 for 3,000 screenshots.
Sign up for ScreenshotNeo’s free 1,000 screenshots a month—no card required.
FAQ
Can I capture every review from every ecommerce site with one endpoint?
No universal endpoint or response format is established here. Inspect the particular page’s requests and confirm what each response contains.
Why are reviews visible in my browser but absent from a crawler’s view?
The page may reveal them only after a user interaction, and Google generally does not click controls that require user action. Site owners should follow Google’s lazy-loading guidance and verify rendered output.
Can ScreenshotNeo show me the hidden review data?
ScreenshotNeo returns a screenshot or PDF of a rendered page. To inspect network responses and review data, use Chrome DevTools.


