Responsive Website Checker: 21 Data Fields per Record (2026)

Each record carries 21 output fields, and every tested web address produces 66 device records across phones, tablets, and desktop viewports. The free-plan price is $2.00 per 1,000 results. Mobile and tablet viewports are measured across both portrait and landscape orientations, returning full-page screenshot links alongside DOM load and paint timings. This Actor is built for frontend engineers and QA teams needing automated cross-viewport layout verification and visual captures. It is not for teams needing authenticated session testing behind login walls, which the single URL input does not support.

Try it: open Responsive Website Checker on Apify, sign in on the free plan and run the prefilled example.

Can you try Responsive Website Checker before paying?

Yes. Apify's free plan includes $5.00 of prepaid usage every month and asks for no credit card. At $0.002 per result, that covers up to 2,500 results of Responsive Website Checker a month, before run-start charges and platform usage.

Responsive Website Checker was last updated on 2026-04-11. It is one of 1,725 Actors CrawlerBros publishes on Apify, which together have 680,173 lifetime public runs and an average rating of 4.63 out of 5 across 416 reviews.

What does it cost to run Responsive Website Checker?

Each result costs $0.002 on Apify's free plan, which is $2.00 per 1,000 results. Starting a run is charged separately at $0.005 per GB of Actor memory. Apify also bills the platform usage each run consumes, at the rates of your Apify plan, on top of these charges.

The length of the urls array dictates the bill, as each entry writes 66 items to the dataset across the preset device matrix. Running a single address writes 66 results, making a one-URL test the leanest way to inspect the payload structure before scaling up. The free plan covers up to 2,500 results of this Actor each month.

How do you run Responsive Website Checker from the API?

The Actor takes a single input, urls, and it is required. The payload below uses the schema's own prefilled values, so it runs as written once you substitute your API token.

Call the synchronous endpoint to start a run and receive dataset items in one request:

curl -X POST "https://api.apify.com/v2/acts/crawlerbros~responsive-website-checker/run-sync-get-dataset-items?token=$APIFY_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"urls":["https://www.example.com"]}'

The same run from Python, using the official client:

from apify_client import ApifyClient

client = ApifyClient("<YOUR_APIFY_TOKEN>")

run_input = {
  "urls": [
    "https://www.example.com"
  ]
}

run = client.actor("crawlerbros~responsive-website-checker").call(run_input=run_input)

for item in client.dataset(run["defaultDatasetId"]).iterate_items():
    print(item)

And from Node.js:

import { ApifyClient } from 'apify-client'

const client = new ApifyClient({ token: '<YOUR_APIFY_TOKEN>' })

const input = {
  "urls": [
    "https://www.example.com"
  ]
}

const run = await client.actor('crawlerbros~responsive-website-checker').call(input)
const { items } = await client.dataset(run.defaultDatasetId).listItems()
console.log(items)

The synchronous endpoint holds the connection open until the run finishes, which is convenient for small batches and wrong for large ones. For anything long running, start the run asynchronously and poll, or attach a webhook, so a dropped connection does not cost you the results.

Which Responsive Website Checker inputs matter, and which can you skip?

The schema exposes exactly 1 controls, and urls is the only input you provide. Supply an array of valid, publicly reachable HTTP or HTTPS web addresses. There are no optional flags or toggles to manage.

• urls (array): Website URLs to test for responsiveness

What does Responsive Website Checker return?

Output items provide diagnostic metrics for frontend quality assurance, including direct screenshot links, layout overflow strings, interactive button counts, and paint benchmarks. The records do not capture browser console errors, network request waterfall traces, or accessibility compliance scores.

• url: The tested website URL
• device_name: Device model name
• orientation: portrait or landscape
• category: mobile, tablet, or desktop
• brand: Device manufacturer
• viewport_width: Viewport width in pixels
• viewport_height: Viewport height in pixels
• device_pixel_ratio: Device pixel ratio (e.g., 2 for Retina)
• screenshot_url: Direct URL to full-page screenshot
• page_width: Actual page content width
• page_height: Actual page content height
• issues: Layout issues detected (if any)
• buttons_count: Number of buttons/clickable elements
• links_count: Number of links
• small_touch_targets: Count of elements smaller than 44px
• dom_load_ms: DOM content loaded time (ms)
• page_load_ms: Full page load time (ms)
• first_contentful_paint_ms: First Contentful Paint (ms)
• transfer_size_bytes: Total data transferred
• tested_at: ISO timestamp of test
• status: success or error

These are the documented fields. Optional ones can be empty on a given record, so measure how often each field your deliverable depends on is populated across a real sample before automating the handoff.

How do you build the workflow end to end?

Open Responsive Website Checker and work through these in order. Each step ends with something to check, so a bad configuration surfaces on a small run rather than a scheduled one.

1. Populate urls with a single fully qualified public web address to run the initial baseline test.
2. Inspect the dataset to verify that exactly 66 items are written for that target domain.
3. Check status on every returned item to ensure each simulated device rendered with a value of success rather than error.
4. Examine issues in each record to verify whether any horizontal overflow warnings or small touch target alerts appeared.
5. Open the screenshot_url link directly from an iPhone and desktop record to visually confirm that images, fonts, and full-page layout rendered cleanly without anti-bot blocks.
6. Inspect first_contentful_paint_ms and dom_load_ms across mobile records to confirm load latency stays within acceptable targets.
7. Expand urls to include the remaining public marketing or staging pages once the initial test domain is verified.

How do you apply it? Three worked playbooks

These are Responsive Website Checker's own documented use cases, each worked through as an operating pattern rather than a description.

Use case 1: Pre-launch testing across all target devices

Outcome: Pre-launch testing across all target devices

Configure: urls: ["https://staging.example.com"]

Working method: Execute a run against the primary staging URL, verify that 66 rows populate the dataset, and sort the output by the issues column to flag every viewport where horizontal overflow occurred.

Deliverable: A consolidated dataset of 66 device records containing direct PNG screenshot links, element counts, and layout validation flags across mobile, tablet, and desktop viewports.

Stop condition: The issues field returns Horizontal overflow on any mobile viewport.

Use case 2: Continuous monitoring after updates

Outcome: Continuous monitoring after updates

Configure: urls: ["https://www.example.com/checkout", "https://www.example.com/pricing"]

Working method: Schedule regular execution after production releases, export the dataset records, and compare buttons_count and links_count against previous baseline counts to detect missing interactive elements.

Deliverable: A recurring dataset recording performance times, element counts, and layout alerts per release cycle.

Stop condition: buttons_count or links_count drops significantly compared to the prior release baseline.

Use case 3: Design validation against mockups

Outcome: Design validation against mockups

Configure: urls: ["https://www.example.com/new-landing-page"]

Working method: Download the PNG files referenced in screenshot_url across Apple iPhone and Mac Desktop rows, then overlay them against designer Figma artboards to confirm breakpoint layout alignment.

Deliverable: A directory of full-page PNG screenshots across mobile and desktop breakpoints matched directly to design mockups.

Stop condition: page_width diverges from viewport_width on target desktop viewports.

What breaks, and how do you design around it?

Because the runner cannot pass authentication cookies, private staging environments must be opened via temporary public bypass URLs or IP allowlists. When websites block headless browser traffic, test a public marketing subpage first to verify whether automation is permitted. For pages with slow third-party widgets, evaluate first_contentful_paint_ms to separate asset bloat from application rendering delays.

When should you not use Responsive Website Checker?

Do not use this Actor when you only need a single quick screenshot of a web address without generating 66 device variants, where Website Screenshot Generator or Ultimate Website Screenshot / PDF / Video is far more targeted. Avoid this Actor if your objective is measuring geographic search rank rather than frontend display; use SEO Service Area Visibility Checker instead. It is also unsuitable for private web applications requiring user logins, form submissions, or custom viewport dimensions, because the schema only accepts raw public addresses and forces a predefined matrix of 66 device tests.

What should you check before trusting the output?

• status equals error on any device record for a public page.
• screenshot_url is blank or fails to resolve to a stored PNG in the run key-value store.
• issues contains Horizontal overflow indicating page_width exceeds viewport_width on a target mobile viewport.
• small_touch_targets returns an integer greater than 0 on mobile viewports where interactive targets must stay above 44px.
• first_contentful_paint_ms exceeds 1500 on mobile device tests.

None of this proves a record is correct. It gives a scheduled Responsive Website Checker run defined points where it should stop instead of quietly passing bad data downstream.

Frequently asked questions

How much does a test run cost?

The free-plan price is $2.00 per 1,000 results, which works out to $0.002 per result. A single tested page produces 66 dataset rows, resulting in an event charge of roughly $0.132 for that run, plus standard Apify platform compute usage.

How many records are created for each submitted URL?

Each submitted URL generates 66 output records. The Actor executes 37 portrait tests and 29 landscape tests across supported Apple iPhone, Samsung Galaxy, Google Pixel, iPad, Android tablet, and desktop screen sizes.

Can I test pages behind an authentication wall?

No. The schema only accepts an array of URLs and does not provide controls for credentials, cookies, or custom headers. Target pages must be publicly accessible on the web for the browser to render them.

Where are the captured screenshots stored?

Every output item contains a screenshot_url pointing directly to a full-page PNG file saved in the run key-value store. You can open these links in a browser or download them programmatically using the Apify API.

Which performance metrics does each record report?

Each record reports first_contentful_paint_ms, dom_load_ms, page_load_ms, and transfer_size_bytes alongside the viewport dimensions and interactive element counts.

Where to go next

When you are ready to run it, open Responsive Website Checker on Apify; the free plan covers up to 2,500 results a month.

Other Actors we maintain for related data:

• Website Screenshot Generator: Capture full-page screenshots of any website as PNG images or PDF documents.
• Ultimate Website Screenshot / PDF / Video: Capture JPEG/PNG screenshots, PDFs, GIFs and MP4s of any website.
• SEO Service Area Visibility Checker: Check a target domain's Google SERP visibility across multiple cities and keywords.
• John Lewis Electricals Scraper: Scrape John Lewis & Partners - a leading UK department-store retailer's electronics catalog.
• CryptoBubbles Coin Performance Scraper: Scrape live cryptocurrency performance data from CryptoBubbles - top 1000 coins with price, market cap, volume, and multi-timeframe performance metrics (1m, 5m, 15m, 1h, 4h, 1d, 1w, 1mo, 3mo, 1y).
• FDA Medical Device Establishment Registry Scraper: Search the FDA's public Medical Device Establishment Registration & Listing database (openFDA) by establishment/business name, owner-operator firm, device name, state, or country.
• Garmin Connect IQ Scraper: Scrape the Garmin Connect IQ Store - watch faces, apps, widgets, data fields and audio for Garmin devices.

Related guides:

• Website Screenshot Generator: Up to 2,500 Free Results a Month (2026)
• Ultimate Website Screenshot / PDF / Video: $2.00 per 1,000 Results
• Building a Custom Intelligence Pipeline with Four Apify Actors

Resources

• Actor documentation, input schema, and pricing: verified against the published Actor on 2026-09-27.

• Actor last updated by its maintainers on 2026-04-11.

• Run outcome figures cover the 30 day public window ending 2026-09-27.

• Responsive Website Checker on Apify