How to Screenshot a WordPress Site in PHP

WordPress still runs a large share of the web, and most WordPress shops already work in PHP — for the theme, for plugins, or for a companion admin tool. That makes a native PHP screenshot integration the natural fit when a WordPress site needs automated captures, whether that is content QA before publishing, a visual archive of a page, or a preview thumbnail for an internal dashboard.

Why WordPress Sites Have Their Own Quirks

• Cookie and consent plugins (Cookiebot, Complianz, CookieYes) inject banners that differ from a hand-rolled cookie notice.
• Page builders (Elementor, Divi, Gutenberg blocks) can lazy-render sections, so a capture taken too early misses content.
• Caching plugins mean the "live" page and what a screenshot sees can briefly diverge right after a content update.
• Full-length posts and pages are usually the actual thing worth capturing, not just the visible fold.

PHP Example

<?php

$curl = curl_init();

curl_setopt_array($curl, [
    CURLOPT_URL => "https://api.prod.ss.snapshot-site.com/api/v1/screenshot",
    CURLOPT_RETURNTRANSFER => true,
    CURLOPT_POST => true,
    CURLOPT_HTTPHEADER => [
        "Content-Type: application/json",
        "x-snapshotsiteapi-key: YOUR_API_KEY"
    ],
    CURLOPT_POSTFIELDS => json_encode([
        "url" => "https://example-wordpress-site.com/blog/latest-post",
        "format" => "png",
        "width" => 1440,
        "height" => 900,
        "fullSize" => true,
        "hideCookie" => true,
        "delay" => 2
    ])
]);

$response = curl_exec($curl);
curl_close($curl);

echo $response;

hideCookie handles the common consent-banner case automatically. delay gives page-builder sections (sliders, animated counters, staggered image galleries) time to finish rendering before the capture fires, and fullSize makes sure the whole post or page gets captured, not just the header.

Practical Recommendations

• Capture after publish, not before. Caching plugins can serve a stale version for a short window right after a save — trigger the screenshot a few seconds after publish, or bust the cache first.
• Use delay generously on builder-heavy pages. Elementor and Divi sections that animate in on scroll need a moment even in a full-page capture.
• Screenshot the logged-out view for public content QA. Admin bars and editor toolbars should not appear in a published-page screenshot — capture the URL as an anonymous visitor would see it.
• Batch by post type. Looping over all published posts or pages via the WordPress REST API (/wp-json/wp/v2/posts) gives you a URL list to feed straight into the screenshot calls above.

Common WordPress Use Cases

• Visual QA before a scheduled post goes live
• Archiving legal, policy, or pricing pages that change over time
• Auto-generating preview thumbnails for an internal content dashboard
• Catching theme or plugin update regressions across key pages

Why PHP Teams Don't Need a Headless Browser Stack

Running a browser fleet just to screenshot WordPress content is a lot of infrastructure for a problem that is really "give me a reliable image of this URL." A plain HTTP call from the same PHP codebase that already runs the WordPress theme or plugin logic is a much smaller surface to maintain, and it renders the page the same way a real visitor's browser would — animations, lazy content, and consent banners included.

If you're not sure whether v1 or v2 fits WordPress's cookie banners and page-builder cleanup needs, see Snapshot API v1 vs v2 vs v3: Which Endpoint Should You Use?.

For teams already comfortable in PHP, Snapshot Site turns WordPress screenshotting into one more API call in the existing stack, not a separate service to run.