How to Capture a Website Screenshot After a WordPress Post Is Published with Make

To capture a screenshot after a WordPress post goes public, create a Make scenario that watches for posts, sends the post’s public URL to a screenshot API, then routes the returned image to storage or another destination. Make documents a WordPress Watch Posts trigger for when a new post is added, but that description alone does not establish that it fires only on publication. Check the live module’s status filters and test the publication behavior in your account before relying on it.

This guide uses Browserless as the do-it-yourself screenshot API example because its documentation describes a screenshot endpoint and request format. The researched sources do not establish the exact binary mapping and storage configuration in Make, so verify those steps with a test scenario.

1. Decide what counts as a published post

Make’s WordPress integration lists Watch Posts as a trigger that “Triggers when a new post is added.” That is the documented wording; it does not say “when a post is published.” A post may be created as a draft and published later, so confirm what the module detects in the WordPress connection and Make account you use.

Open Make and create a scenario.
Add the WordPress Watch Posts module and connect the site.
Inspect its available filters and status fields. If the module exposes a status, configure the scenario to continue only for published posts.
If it does not reliably detect the transition from draft to published, do not assume it will. Consider a trigger that explicitly reports publication, or a webhook-based design if your site already sends a suitable event. Make documents instant webhook execution when a request reaches a webhook URL, but the sources here do not establish a particular WordPress webhook setup.

Make’s webhook guidance distinguishes instant triggers from scheduled triggers, which periodically check for new data. A polling trigger can introduce a delay between publication and capture; the actual interval depends on the scenario schedule and account configuration.

2. Choose how to handle posts already on the site

When first activating a polling trigger, decide whether to process existing posts or only future ones. A Make Community answer recommends choosing From now on when the goal is to process only future data. Treat this as community troubleshooting guidance, not a guarantee for every trigger or account.

Future posts only: use the trigger’s starting-point option if available, and check the setting before enabling the scenario.
Existing posts too: plan a separate backfill or choose an earlier starting point only if the module supports it. Test with a small range to avoid unintentionally generating many captures.
Prevent duplicates: use the WordPress post ID or public URL as a deduplication key if your scenario can receive the same post more than once.

3. Add the screenshot API request

Add Make’s HTTP Make a request module after the WordPress trigger. Map the post’s public URL into the screenshot request. Browserless documents a POST /screenshot endpoint, JSON request content, a token query parameter, and image bytes in the response. Its example supports PNG output and a full-page option.

Keep your API token in Make’s connection or protected secret field where possible. Do not put a real token in a public tutorial, scenario screenshot, or shared log.

Browserless request example

curl -X POST \
  'https://production-sfo.browserless.io/screenshot?token=YOUR_BROWSERLESS_TOKEN' \
  -H 'Content-Type: application/json' \
  --data '{
    "url": "https://example.com/new-post/",
    "options": {
      "fullPage": true,
      "type": "png"
    }
  }' \
  --output post.png

Replace the example URL with the mapped public URL from the WordPress trigger. Use the endpoint hostname and authentication format from your Browserless account’s current documentation. This command saves the returned response body as an image file; in Make, configure the HTTP response and downstream module to pass the response as binary data, then verify it with a test run.

Configure the Make HTTP module

Set the method to POST and enter the documented Browserless screenshot endpoint for your account.
Provide the token using the documented query parameter. Keep it secret.
Set the request body type to JSON and map the WordPress post’s public URL into url.
Set screenshot options such as full-page capture and output type according to the endpoint documentation. The documented example uses fullPage and type.
Run the scenario with a known public post. Inspect the response status, headers, and body type. Confirm the response is image data, not an error payload.
Add a storage or delivery module and map the HTTP response body into its file or attachment input. The exact field names depend on the destination app; verify the saved file opens as an image.

4. Route and check the resulting image

After the HTTP action, send the returned image to the destination your workflow needs. Common destinations include cloud storage, an email attachment, or another processing step. The sources establish that the screenshot API returns image bytes, but do not validate a particular Make storage module or its field mapping.

Use a descriptive filename, for example wordpress-POST_ID.png.
Preserve the post URL and post ID alongside the file so you can trace a capture back to its source.
Check that Make treats the response as binary file content. Mapping a text representation of the response instead can produce a file that is present but cannot be opened as an image.
Handle failed HTTP responses separately from successful image responses so an error message is not saved with an image extension.

5. Tune rendering for the public page

A capture can happen before the page is visually ready, or it can show a redirect, consent dialog, CAPTCHA, or access-denied screen. Browserless documents waiting options and notes that blocked sites can result in blank, CAPTCHA, or access-denied captures. Choose a wait strategy supported by the screenshot endpoint and test it against the actual site.

Wait for page content: where supported, wait for a stable selector that appears in the published article.
Wait for delayed rendering: where supported, use a delay or a network-idle condition if the page loads content asynchronously. These strategies can increase capture time.
Check the URL: use the public canonical page URL, not an editor or preview URL that requires a logged-in session.
Check access: confirm the page can be opened from outside the WordPress admin session. Automated browser access may be blocked by the site or a security layer.
Check the image: run a manual test and inspect whether the article, rather than a draft, redirect, banner, or block page, is visible.

6. Test before enabling the scenario continuously

Publish a test post that is publicly accessible.
Run the scenario once and inspect the trigger output. Confirm the post status and public URL are the expected values.
Inspect the HTTP action’s request mapping and response. Confirm the response is an image and the capture contains the post.
Check the destination file or attachment, including its size, format, and ability to open.
Test a draft and, if relevant, a post changed from draft to published. Confirm the scenario behavior matches your intended rule.
Only then enable the scenario schedule or leave the instant trigger active.

Common problems and fixes

Symptom	Likely cause	What to check
A draft triggers a screenshot, or a published post is missed	The Watch Posts trigger’s behavior or available status filter differs from the assumed publish-only behavior.	Inspect the live module fields and test both a new draft and a draft-to-published transition. Add a status filter if available; otherwise use a trigger that reliably signals publication.
Old posts run as soon as the scenario starts	The polling trigger starts from an earlier point in the dataset.	Review its starting-point setting. Make Community guidance suggests “From now on” for future items only, but confirm the option and behavior for this module.
The screenshot is blank or shows a CAPTCHA/access-denied page	The page may block automated browser access, or the capture may occur before useful content is available.	Open the public URL without an admin session, inspect the captured image, and adjust supported wait settings. Browserless documents these possible blocked-page results.
The output file is not a valid image	Make may be mapping an error body or text instead of the binary response.	Inspect the HTTP status and response body type. Map the successful response’s binary content to the destination’s file input and rerun a test.
The token is rejected	The token is missing, invalid, or not placed where the endpoint expects it.	Check the current endpoint and authentication format in your Browserless account documentation. Keep the token private.
The image captures a redirect, preview, or login page	The trigger supplied a non-public URL, or the page requires authentication.	Map the post’s public URL and verify it in a logged-out browser session. Do not assume a private preview URL is accessible to the screenshot service.
The scenario runs more than once for a post	The trigger or scenario may deliver repeated records, or a retry may repeat downstream work.	Use a stable post ID or URL to track completed captures and avoid saving duplicates.

Performance, reliability, and cost considerations

End-to-end time includes trigger latency, page rendering, any configured wait, and the destination upload. Polling schedules add detection delay; longer waits can improve the chance that delayed content is present but make each run take longer. Full-page images can also be larger than viewport captures, so consider the destination’s file-size limits and your actual use for the image.

For reliability, keep the post ID and URL with the result, inspect API status before routing the body as an image, and make retries safe by checking for an existing capture. Test pages with redirects, delayed content, consent interfaces, and access controls that occur on your real site. The available research does not establish comparative service pricing, uptime, success rates, or a tested Make binary-storage configuration; check current vendor terms and validate your own scenario.

Or skip the browser setup

ScreenshotNeo is a website screenshot API and MCP server. Send one GET request with the published page URL to get a PNG, JPEG, WebP, or PDF. Its API documentation covers the request options.

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

import requests

r = requests.get(
    "https://api.screenshotneo.com/v1/shot",
    params={"access_key": "YOUR_API_KEY", "url": "https://example.com/new-post/"},
    timeout=90,
)
open("post.webp", "wb").write(r.content)

const q = new URLSearchParams({
  access_key: 'YOUR_API_KEY',
  url: 'https://example.com/new-post/'
});
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`Screenshot request failed: ${res.status}`);
await Bun.write('post.webp', res);

In Make, call the ScreenshotNeo endpoint with the mapped public post URL and your access key, then route its response through the same binary-file check described above. ScreenshotNeo removes cookie banners, newsletter popups, and chat widgets before capture; bot checks, blank pages, and failed loads are never billed; an 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. Check the response and billing headers when handling results. Sign up for 1,000 free screenshots a month with no card.

FAQ

Does Watch Posts run only when a WordPress post is published?

The documented description says it triggers when a new post is added. It does not by itself confirm publish-only behavior. Check the live module’s status options and test publication transitions.

Can I capture posts that were already published before I created the scenario?

That depends on the trigger’s starting point and whether you run a separate backfill. Choose the starting behavior deliberately and test on a small set first.

Can the screenshot be sent to email or storage?

Yes, the workflow can route the image response to a destination module, but the exact binary mapping depends on the destination. Verify that the saved attachment is a valid image.

Why might the capture show a CAPTCHA?

The site can restrict automated browser access. Check the public page and the screenshot response, and review the screenshot provider’s guidance for blocked pages.

Sources

Make WordPress integration — Watch Posts trigger and integration modules.
Make Webhooks help — instant webhook execution and scheduled polling concepts.
Make HTTP integration — Make a request action for API calls.
Browserless Screenshot API documentation — request format, image response, options, and blocked-page notes.
Make Community discussion — community guidance on starting a polling trigger from now on.