Apify Website Screenshot Actor Not Loading Images: Troubleshooting

If images are missing from an Apify screenshot, first confirm that the run uses Apify’s official apify/screenshot-url Website Screenshot Generator. Then compare the same page in a normal browser, test a different navigation wait condition or a short post-load delay, and inspect the run logs. These settings can help with content that renders late, but they do not guarantee that every image loaded.

The official Actor’s documented settings include navigation wait conditions, a post-load delay, a page-load timeout, retries, viewport dimensions, and PNG or JPEG output. The schema reviewed for this guide does not document a dedicated image-wait or scroll-to-bottom setting. For lazy-loaded images, that limitation matters: waiting for navigation to finish does not necessarily trigger content that appears only after scrolling.

1. Confirm which Apify Actor is running

Apify Store includes similarly named screenshot Actors, and their inputs are not interchangeable. The steps below apply to the Apify-maintained Website Screenshot Generator, apify/screenshot-url. Check the Actor ID on the run page before copying settings or examples.

The official Actor takes one or more URLs and stores screenshots in a key-value store. If you are running a different Actor, use that Actor’s own input schema and documentation. In particular, do not assume an input called waitForImages, scrollToBottom, or waitForSelector exists just because another screenshot Actor offers it.

2. Diagnose the missing image before changing settings

1. Open the exact URL in a regular browser. Use roughly the same viewport as the screenshot run. Check whether the image appears without signing in, accepting a prompt, or taking another action.
2. Scroll to the missing image. Some pages request an image only when its element approaches the viewport. If it appears only after scrolling, the issue may be lazy loading rather than the navigation wait condition.
3. Check the image URL and page access. A broken source URL, expired signed image link, hotlink restriction, login wall, or site-level error can leave the browser with no image to capture.
4. Compare the viewport. Responsive sites can use different markup, image sources, or layout rules at different widths. Reproduce the Actor’s viewport dimensions in your browser before drawing conclusions.
5. Inspect the run output and logs. Look for navigation errors and timeouts. A successful navigation does not prove that every individual image request succeeded.

If the page itself does not show the image in a normal browser, start with the page, its access requirements, and its image source. A screenshot Actor cannot capture pixels the page did not render.

3. Test the official Actor’s loading controls

The official input schema documents these controls for load timing and capture:

Input	Documented choices or range	How to use it for this issue
waitUntil	load (default), domcontentloaded, networkidle0, networkidle2	Try one condition at a time. This controls when navigation counts as successful; it is not a guarantee that all images are visible or loaded.
delaySecs	0–120 seconds; default 0	Try a modest delay if scripts render images after navigation. Treat it as an experiment, not a guaranteed fix.
pageLoadTimeoutSecs	1–180 seconds; default 60	Increase it when navigation itself is slow or timing out. It does not selectively retry image requests.
pageMaxRetryCount	0–10; default 2	Use retries for navigation errors or timeouts, not as proof that missing images will be fetched on retry.
viewportWidth and viewportHeight	Positive integer dimensions; defaults 1200 by 900	Match the viewport where the image is visible. A different viewport can trigger a different responsive layout.
imageType	jpeg (default) or png	Choose an output format for the screenshot. Changing the format does not make an unloaded source image appear.

The Actor listing and input schema are the authority for current field names and constraints. See the official Actor page before changing a production task.

4. Run a controlled timing comparison

Change one timing setting at a time and compare the result. Start with the default, then test a different waitUntil value, and then add a short delaySecs. Keep the URL and viewport fixed so the result is interpretable.

Here is a runnable cURL request using the official Actor’s synchronous endpoint. Replace YOUR_APIFY_TOKEN and adjust the JSON input for the condition being tested:

curl -X POST \
  "https://api.apify.com/v2/actors/apify~screenshot-url/run-sync-get-dataset-items?token=YOUR_APIFY_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "urls": [{"url": "https://example.com"}],
    "waitUntil": "load",
    "delaySecs": 3,
    "pageLoadTimeoutSecs": 60,
    "pageMaxRetryCount": 2,
    "viewportWidth": 1200,
    "viewportHeight": 900,
    "imageType": "png"
  }'

The official Actor’s API page documents the run endpoint and input format. See Website Screenshot Generator API documentation.

Use the following order for a small comparison:

1. Run with the current input and save the output for reference.
2. Try waitUntil: "load" if you were using domcontentloaded, or compare a network-idle option if the page’s content depends on ongoing scripts.
3. Add a short post-load delay, such as three seconds, only after recording the result without one.
4. Increase pageLoadTimeoutSecs only if the run shows that navigation times out or takes longer than the current limit.
5. Repeat at a viewport where the image is visible in a normal browser.

networkidle0 and networkidle2 can be unsuitable for pages with persistent requests. If a run waits too long or behaves inconsistently, compare another documented condition rather than assuming network idle is always best.

5. Account for lazy-loaded and below-the-fold images

Lazy-loaded images are often requested only after scrolling or when the browser decides an image is close enough to the viewport. A navigation wait condition and a fixed delay do not necessarily cause that scroll. The official apify/screenshot-url schema reviewed here does not document a dedicated waitForImages or scroll-to-bottom input, so do not add guessed fields and expect them to work.

If the missing images appear only after scrolling in a normal browser:

• Confirm whether the task needs a viewport screenshot or a full-page screenshot.
• Check the exact Actor schema for an explicit scrolling or image-wait feature before selecting another Actor.
• If you switch Actors, verify who maintains it and what its input settings actually do. A community Actor may expose image waiting or scrolling, but those controls belong to that Actor and are not settings for apify/screenshot-url.
• For a page you control, consider whether its lazy-loading behavior can be adjusted for the capture workflow, or use a browser-based capture process that explicitly scrolls and waits for the desired content.

For general background, the browser’s native lazy-loading behavior is described by MDN’s lazy-loading guide. The practical point is to distinguish “navigation completed” from “the browser triggered every below-the-fold image.”

6. Check the run result and logs

The Actor’s timeout and retry inputs apply to page navigation errors and timeouts. Increasing the timeout can help a slow page finish navigating; increasing retries can help with intermittent navigation failures. Neither setting tells you whether a particular image request returned successfully.

When reviewing a run, record the Actor ID, input JSON, target URL, viewport, selected wait condition, delay, and whether the image appeared in a normal browser. This makes comparisons useful and helps separate navigation failures from image loading or page behavior.

7. Avoid using a text crawler for a visual capture

A text-extraction crawler and a screenshot Actor serve different purposes. In a response on Apify’s community forum, an Apify representative explained that the Website Content Crawler is intended for text extraction and loads pages without visual resources such as CSS and images; the representative recommended the Website Screenshot Generator for webpage screenshots. If your run uses a crawler rather than a screenshot-focused Actor, switch to a tool designed to render a visual page.

8. Troubleshooting by symptom

Symptom	Likely cause	Next step
Images are missing in both the screenshot and browser	The page or image source did not provide them, or access depends on a condition not met in either session.	Open the image source, check access requirements, and confirm the URL works in a regular browser.
Images appear in the browser only after scrolling	Lazy loading has not been triggered before capture.	Check whether the selected Actor explicitly supports scrolling or image waiting. The official schema reviewed here does not document those inputs.
Images appear after a pause but not immediately	Client-side code may render them after navigation.	Compare a short delaySecs value against the default, changing no other setting.
The run times out or navigation is slow	The page did not meet the selected navigation condition within the current limit.	Inspect logs, test another documented waitUntil condition, and increase the page-load timeout if needed.
Results vary between runs	The site may render content at different times or use dynamic page behavior.	Keep viewport and URL constant, compare wait settings, and use a modest delay only if it improves results consistently.
Settings are rejected or have no effect	The input may belong to another similarly named Actor or may use the wrong field name.	Confirm the Actor ID and copy the input names from that Actor’s current schema.
The screenshot shows text but no images or styling	The run may be using a text-extraction crawler.	Use a screenshot-focused Actor intended to render the page visually.

9. Performance, reliability, and cost considerations

Longer delays and more demanding navigation conditions can increase the time each run takes. Use the shortest delay that reliably captures the content you need, and avoid raising timeouts or retry counts unless run results show navigation is slow or intermittent. Retries are not a substitute for a page-level image-loading strategy.

For repeat captures, keep inputs consistent and compare results across a few runs before using them in monitoring or another automated workflow. Treat each capture as a rendering at a particular URL, viewport, and point in time; dynamic page content can change between runs.

The official Actor listing describes its output as being stored in a key-value store and provides API access for running it and retrieving results. This guide does not quote an Apify platform price: costs depend on current platform terms and usage, so check the current listing and your account before running at scale.

10. Or skip the browser setup

ScreenshotNeo is a website screenshot API and MCP server from Yorker Media. One GET request returns a screenshot or PDF. It accepts cookie and consent banners like a visitor and removes more than 60 known consent platforms, newsletter popups, and chat widgets before capture; each of those steps can be turned off. Only clean shots are billed: bot checks, CAPTCHAs, blank pages, timeouts, failed loads, and cache hits cost nothing, and responses identify the page verdict and billing status in headers. Its MCP server provides take_screenshot, get_page_info, and capture_pdf tools for AI agents.

For this target, the direct request is:

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

See the ScreenshotNeo API documentation for request options. Cookie banners, popups, and chat widgets are removed before the shot; bot checks, blank pages, and failed loads are never billed; the MCP server lets AI agents take screenshots; and 1,000 screenshots a month are free with no card, with paid plans starting at $5 for 3,000. Sign up for the free plan.

FAQ

Does waitUntil: "load" guarantee every image is loaded?

No. It is a navigation completion condition, not a guarantee that all images are visible or that below-the-fold lazy-loaded content has been triggered.

Should I set the maximum timeout and retry count?

Only when run evidence points to slow or intermittent navigation. Those settings do not specifically retry failed image requests.

Can I use waitForImages with the official Actor?

Do not assume so. The official schema reviewed for this guide does not document that input. Check the current schema before using any field.

Why do similarly named Apify screenshot Actors have different settings?

Apify Store Actors can be maintained by different developers and implement different inputs. Confirm the exact Actor ID and follow its own documentation.