DEV Community: orange

I Had an AI Agent Scrape Google Maps Instead of Writing a Scraper. Here's What It Cost.

orange — Sat, 12 Sep 2026 03:16:57 +0000

Summary: I ran a Claude agent with only browser tools (no pre-written scraper code) against 60 coffee-shop listings on Google Maps across 3 US cities, and compared it to a plain Playwright script on the same pages. The agent got every field right on every checked row, but cost 190k-540k processed tokens and 23-35 seconds per place, against 6-14 seconds and zero model tokens for the script. Full numbers and caveats below.

A thread in r/automation asked whether an LLM agent could just replace a scraper for a simple site instead of someone writing selectors. I didn't answer with an opinion. I ran it.

The setup

The agent was Claude Sonnet with browser tools only: open pages, search inside them, pull page text, run JavaScript in the page. No scraper was written for it in advance; the only code involved was short in-page JavaScript the agent itself wrote and ran during the runs. It searched Google Maps for "coffee near " and collected name, rating, review count, address, and phone for each result.

I ran it four times: two passes over the same 10 places in Times Square, NYC (to check repeatability), one pass over 10 places in Union Square, SF, and one pass over 30 places in Millennium Park, Chicago. 60 place records total, all in the US, all on one site. An earlier Shibuya pass is excluded entirely; none of its numbers appear here.

Token and context numbers came from a small script (measure.py) that reads the agent's own transcript (JSONL) and sums usage fields per model call. "Processed" is the raw sum of every token count the API reported across all calls, cache reads included. "Weighted" is the same usage with plain input counted at 1x, cache reads at 0.1x, cache writes at 2x, and output at 5x, an internal cost proxy I use to compare runs, not a real price. I did not compute a dollar cost for this test.

Before the agent even opens a page, its context already sits around 31k tokens (system prompt, tool definitions, instructions). Every number below is on top of that baseline.

The agent runs

Run	Target	Rows	Tool uses	Model calls	Wall	Context end	Tokens processed	Weighted
1	Times Square NYC, 10	10/10	47	54	292 s	87k	2.93M	492k
2	Times Square NYC, 10 (repeat)	10/10	63	70	347 s	108k	5.38M	781k
3	Union Square SF, 10	10/10	58	67	290 s	77k	3.64M	507k
4	Millennium Park Chicago, 30	30/30	74	86	680 s	123k	5.67M	804k

Per-place cost isn't flat. Run 1: about 29 s wall, 293k processed, 49k weighted per place. Run 4, which had 3x the places: about 23 s wall, 189k processed, 27k weighted per place, the cheapest per-record run of the four.

That drop wasn't from the agent getting more efficient at reading pages generally. In run 4 it switched strategy: instead of using its general-purpose "find" and "get page text" tools on each place page, it ran one JavaScript call per page that pulled the values straight out of aria-label attributes. That one change is most of why the per-place number fell.

Runs 1 and 2 did the exact same task (same 10 places) back to back, and the numbers weren't identical: wall time was 19% higher and weighted tokens were 59% higher on the second run. That run also hit a stalled results feed (a spinner stuck at 6 loaded items) and needed a page reload plus a scripted scroll to recover, which explains most of the gap.

Cost also isn't flat within a single run. For run 4, splitting its calls into thirds and summing context per third gives 1.15M, then 1.64M, then 2.88M: the last third cost about 2.5x the first, because each new call has to re-read a context that keeps growing across the whole run.

The script baseline

For comparison, a Sonnet worker (a different, non-browsing agent) wrote a plain Playwright script from a one-paragraph spec, with one iteration to fix the reviews-count wait condition. After that, the script ran with zero model tokens per record; it's ordinary code. To be precise about scope: the script only re-fetched place pages whose URLs the agent had already found. It never did its own search or list discovery on Google Maps, so this is "script vs. agent on fetching a known page," not the whole search-and-collect task.

Set	URLs	Wall	Per URL	Reviews empty	Failures
NYC 10	10	61 s	6.1 s	6/10	0
SF 10	10	100 s	10.0 s	7/10	0
Chicago 30	30	420 s	14.0 s	15/30	1 (h1 never appeared)

The script's weak spot was the review count, which loads via an async widget: it came back empty on 28 of 50 rows across these three sets, and one Chicago row failed outright (the page's h1 never became visible within the wait, a Playwright timeout). The agent had 0 empty reviews across all 60 rows, because it also read the search results feed, not just the place page, and could fall back to that.

Per-URL time also rose over the 30-URL Chicago batch. Seven of its 30 rows took 32-36 seconds each, and those were exactly the rows that came back with an empty review count; the other rows took 2-7 seconds, apart from the one failed fetch. The 10-URL SF batch had one such 32-second row out of ten, and the NYC batch none. That's consistent with some kind of throttling or soft bot-detection building up over a long single-browser run, but I didn't isolate the cause; I'm flagging it, not claiming it.

Accuracy

I checked the agent's 60 rows against the script's output field by field: name, rating, address, phone, reviews. Zero true value mismatches on name, rating, address, or phone across all 60 rows. Reviews couldn't be checked on 28 of those rows because the script itself came back empty there (not a disagreement, just missing data on the script's side), plus the one hard failure already mentioned.

For the rows the script couldn't confirm, a separate browser-driven check re-read the live page directly (scoped JavaScript on the rating widget, address button, and phone button aria-labels). That covered every row the script had left unverified, 29 in total including the failed row, and all 29 matched the agent's original values, including one case where the review count had genuinely ticked up between the agent's run and the recheck (3563 to 3564 on one shop), which is live drift, not an error.

Put together: 60 rows times 5 fields is 300 field checks, 0 confirmed errors. To be exact about "confirmed": every value was checked by a script and, where the script came up empty, by a second automated browser read of the live page. No human visited any of these 60 shops or looked them up independently outside those two automated checks.

Two things worth naming. One shop's address is shown on the page as "10036 326 W 47th St, New York, NY 10036" (an odd leading zip code, which the script also captured verbatim). Agent run 1 copied it as-is; agent run 2 wrote "326 W 47th St, New York, NY 10036", dropping the leading token without saying so. Arguably a sensible cleanup, but it is one silent edit of a source value in 300 fields, and the kind of thing you'd want an agent to flag rather than fix quietly. And the first attempt at the browser recheck itself grabbed a value from a "related places" carousel card once instead of the page's own header, before I fixed it by anchoring to the specific rating widget, a trap that applies to any extractor, agent or script.

What I'd conclude

The agent produced correct data with no scraper code written in advance, using only generic browser tools (search, page-text reads, in-page JavaScript). By the last run it had converged on a script-like approach anyway: one targeted JavaScript extraction per page. The "no-code" agent's cheapest, most reliable mode still looked like a hand-written extractor; it just wrote and ran that extractor itself, per page, inside the same conversation.

The honest trade-off: the plain script is roughly 1.6x to 5.7x faster per URL (6.1-14 s versus 23-35 s) and burns zero model tokens once written, but is brittle on anything that loads asynchronously (reviews here) and can hard-fail on an unexpected page structure. The agent is slower and far more expensive per record (tens to hundreds of thousands of tokens versus none), but degrades more gracefully: when one source was empty, it used another. For a recurring job, the agent's token cost scales with time per record and with how much context accumulates in a single run, which grew noticeably over a 30-item batch.

Can the cost be cut?

The obvious lever is the number of model calls, since every call re-reads the whole context. So I tried the split that the agent itself drifted toward: let the plain script do the bulk, and use the agent only for the rows the script could not fill (the 28 empty review counts and the 1 failed fetch, plus 2 rows I had missed in the first pass, 29 rows in all). The agent re-read those 29 rows in the browser with a handful of batched calls.

Approach (same 50 places)	Model calls	Wall	Tokens processed	Weighted
Agent only (runs 1, 3, 4)	207	1,262 s	12.24M	1,803k
Script for all 50 + agent for the 29 gap rows	34	1,088 s	2.88M	519k
One-time: writing the script (a Sonnet worker, 1-paragraph spec, 1 iteration, incl. a first 10-URL run)	66	744 s	-	516k

Weighted tokens fell by 71%, wall time by 14%. Even with the one-time cost of writing the script, the first batch of 50 came out cheaper than running the agent on everything (1,035k versus 1,803k weighted).

Two things inflate that number in the hybrid's favor. The script never did list discovery; it re-fetched place URLs the agent had already found, and I did not measure what discovery would cost a script. And the gap-filling agent read its 29 rows in just 4 batched browser calls (23 model calls for the first 27 rows), so part of the saving is plain batching, not the split itself. Run 4 spent 86 calls on 30 rows; the same batching applied to a full agent run would cut its cost too. So I ran the Chicago 30 again the next day with the agent following a recipe I wrote from its own earlier transcript: scroll the list with real wheel events, extract all cards in one JavaScript call, then for each place one batched call of navigate, wait, and a JavaScript read of the aria-labels.

Chicago 30	Model calls	Wall	Context end	Tokens processed	Weighted
Run 4: agent chose its own method	86	680 s	123k	5.67M	804k
Run 5b: agent following a written recipe	41	512 s	92k	2.26M	623k

Calls fell by 52% and processed tokens by 60%, but weighted tokens only by 23%: what remains is output and cache writes, which batching does not remove. Two scroll batches were wasted because my scroll coordinate missed the list panel, and one small screenshot was needed to see why. The honest framing is that run 5b measures an agent following a human-written recipe, which is most of the way to a script. Accuracy held: the same no-model script confirmed name, rating, address and phone on the 28 rows it could fetch (it timed out on 2, both branches of the same chain), and the review counts it left empty match the previous day's verified values within live drift. A browser re-read confirmed the two rows the script failed on (name, rating, review count, address and phone all matched).

What I did not test

Anything beyond these 60 places across 3 US cities on one site. No other verticals, countries, or the earlier Shibuya pass.
List discovery cost for the script: it only re-fetched place-detail URLs the agent had already found, never its own search or scroll-and-collect.
Whether the per-URL slowdown in the 30-item batch was really throttling; I noticed the pattern but didn't isolate the cause.
Dollar cost. Weighted numbers are an internal proxy, not a price.
Thousands of records, or any site besides Google Maps.

This was a personal measurement, not a client project or anything running in production.

I also publish Google Maps related actors on Apify Store (https://apify.com/reverenced_garnet).

Checking If a Business's Google Profile Actually Matches Its Own Website

orange — Sun, 06 Sep 2026 03:50:33 +0000

If you do local SEO work, you've run into this: a Google Business Profile says one phone number, the website footer says another, and nobody noticed until a customer called the wrong number. Or the postal code on the GBP listing is a leftover from an old office. This kind of drift is called a NAP (Name, Address, Phone) inconsistency, and it's widely cited as a local search ranking factor. But checking it by hand means opening every listing and every website side by side.

I built Google Maps NAP Consistency Checker, an Apify Actor that takes Google Maps scraper output, fetches each business's own website (lightly: homepage plus one likely subpage), and checks whether the name, postal code, and phone number on the Google Business Profile actually show up on the site.

What it does, and what it doesn't

This Actor checks one thing: does a business's own website agree with its Google Business Profile on name, postal code, and phone number. It does not check third-party directories (Yelp, Facebook, etc.). That's a different problem with a different competitor landscape. It does not crawl an entire website; it fetches at most two pages per business (homepage, plus a subpage if one with a keyword like "contact" or "about" is linked from it). It does not use an LLM. It's regex and string matching against fetched text, which makes it fast, cheap, and predictable. There's no model that can hallucinate a match that isn't there.

Businesses with no independent website (only a social profile, or nothing) are skipped entirely, because there's nothing to fetch and compare against.

How it works

For each place with a real website, the Actor:

Checks robots.txt for that domain before fetching anything, and skips the business if the checker's user agent isn't allowed.
Fetches the homepage HTML (up to 3 MB), strips <script>, <style>, and comments before converting to text, so JavaScript variables and tracking IDs don't get misread as phone numbers.
Looks for an internal link containing a keyword like "contact," "about," "access," or "info" (also handles Japanese equivalents), and fetches that one extra page if found. Mail and tel links and JS pseudo-links are excluded from that search. An early version tried to fetch mailto:info@... as if it were a page URL, which is exactly the kind of bug you only find on real sites.
Pulls out href="tel:..." numbers directly (a strong signal), plus any phone-shaped strings in the visible text, covering Japanese formats (03-6434-9090) and US formats ((512) 828-3835, +1 512-828-3835).
Compares postal code and phone number found on the site against what the Google Business Profile has, using the scraper's own postalCode field when available, with digit-only and hyphenated variants both checked so formatting differences don't cause false mismatches.
Checks whether a meaningful fraction of the business name's word tokens appear anywhere on the page, as a rough "is this even the right site" sanity check.

Every result also gets a changeStatus: run it again later on the same list and matches that were previously flagged as mismatched but are now fine get tagged FIXED. Useful for proving a flagged issue actually got fixed on a later run.

Usage

Apify Console

Run a Google Maps scraper (e.g. Google Maps Scraper) for the businesses you want to audit.
Open Google Maps NAP Consistency Checker, paste that dataset array into the Google Maps places field.
Click Start. You're billed per business actually checked. Places with no independent website are skipped for free.

Chaining two Actors with apify-client (Python)

from apify_client import ApifyClient

client = ApifyClient(token="YOUR_APIFY_TOKEN")

# 1. Scrape a set of businesses
scrape_run = client.actor("compass/crawler-google-places").call(
    run_input={
        "searchStringsArray": ["plumber in Austin, TX"],
        "maxCrawledPlacesPerSearch": 100,
    }
)
places = list(client.dataset(scrape_run["defaultDatasetId"]).iterate_items())

# 2. Check NAP consistency for each business's own website
nap_run = client.actor("reverenced_garnet/apify-gmaps-nap-checker").call(
    run_input={"places": places}
)
results = list(client.dataset(nap_run["defaultDatasetId"]).iterate_items())

mismatches = [r for r in results if r["reasons"]]
print(f"{len(mismatches)} of {len(results)} checked businesses have a NAP issue")

Input

Field	Type	Description
`places`	array (required)	Place objects from a Google Maps scraper's dataset output. Only places with their own (non-social-media) website are checked. The rest are skipped.

Output

{
  "title": "Ultimate Plumber",
  "placeId": "ChIJv79rmEfzGGARhXlSEd8ceiQ",
  "fetchedOk": true,
  "postalMatch": true,
  "phoneStatus": "match",
  "nameFoundOnSite": true,
  "changeStatus": "FIXED",
  "reasons": []
}

Field	Type	Description
`title`	string	Business name
`placeId`	string	Google Maps place ID
`fetchedOk`	boolean	Whether the website could be fetched at all (`false` means every other field is unknown, not "matching")
`postalMatch`	boolean or null	Whether the GBP postal code appears on the site; `null` if there wasn't enough data on either side to compare
`phoneStatus`	string	`match`, `mismatch`, `gbp_missing_on_site_found`, `site_missing_gbp_has`, `both_missing`, or `unknown`
`nameFoundOnSite`	boolean or null	Whether most of the business name's word tokens appear on the page
`changeStatus`	string	`NEW`, `UPDATED`, `UNCHANGED`, or `FIXED` versus the previous run on this Actor
`reasons`	array	Plain-English list of what didn't match

Note that fetchedOk: false and postalMatch: null are deliberately kept separate from a plain "no mismatch found." If the site couldn't be fetched, or there wasn't a postal code to compare on one side, the Actor says so instead of quietly reporting a false match.

Use case: auditing NAP consistency before a local SEO engagement

Hypothetical workflow: a common first step for a local SEO agency taking on a new client, or a freelancer building a pitch:

Scrape the client's own listing (or every location, for a multi-location business) with a Google Maps scraper.
Run it through this Actor to see whether the phone number and address on the GBP listing actually match the website.
Use phoneStatus: gbp_missing_on_site_found as a quick, low-effort recommendation: "your GBP is missing a phone number your own site already lists, this is a five-minute fix."
Schedule it monthly with Apify's Scheduler if you're monitoring an account over time, and use changeStatus: FIXED as evidence the fixes actually got made.

The same pattern applies to a directory or citation-management tool that wants a quick pre-check on whether a business's own site agrees with itself before flagging bigger discrepancies elsewhere.

A note on scope and responsible use

This Actor fetches at most two pages per business, respects robots.txt for the domain being checked, and identifies itself with its own user agent string. It's not a general-purpose crawler. It only looks at data that's already public on the business's own Google Business Profile and website. It's still worth being explicit that finding a phone number or address on a public page doesn't by itself give you consent to use it for outreach; if you use anything found here for contacting a business, you're responsible for complying with applicable law in your jurisdiction.

Pricing

Pay-per-event: $0.01 when a run starts, plus $0.01 per business actually checked (only businesses that had a website to fetch). Auditing 100 locations costs about $1.01. Places with no independent website are skipped and not charged. Current pricing is always on the Store page.

Try it

The Actor is live on the Apify Store: Google Maps NAP Consistency Checker. I built this as part of a small set of post-processing Actors for Google Maps scraper output. If you're already running a scraper for local SEO or lead work, this is a cheap add-on step to catch a class of embarrassing public-facing errors that's otherwise easy to miss.

Turning Google Maps Scraper Output into a 0-100 Lead Priority Score (No Scraping, No LLM)

orange — Sat, 05 Sep 2026 23:56:11 +0000

If you've ever looked at a lead-gen pipeline for a local SEO or web design agency, you know the pattern: scrape a bunch of businesses off Google Maps, then manually eyeball which ones are worth calling. Missing website? Good lead. Unclaimed Google Business Profile? Also good. Both? Great lead. But sorting hundreds or thousands of rows by hand on multiple criteria doesn't scale.

I built Google Maps Lead Priority Scorer, an Apify Actor that takes the JSON output you already have from a Google Maps scraper and turns it into a single sortable priorityScore (0-100) per business, plus a plain-English list of reasons. It does no scraping and makes no LLM or external API calls — it's pure post-processing of data you already paid to collect.

The problem with single-signal lead lists

Most "find leads with no website" tools give you exactly one signal. But a business that has no website and an unclaimed GBP listing and fewer reviews than its neighbors is a categorically hotter lead than one that's just missing a website. If you're running four separate scrapers/filters and merging spreadsheets by hand, you're doing manual work a scoring function should do for you.

This Actor combines four signals into one number:

Signal	Max points
No independent website (a bare social-media link doesn't count)	35
Unclaimed Google Business Profile	25
Other missing profile fields (phone, description, hours, photos, categories)	25
Review count below the median for similar nearby businesses	15

Scores map to tiers: Hot (≥70), Warm (40-69), Cold (<40). Businesses marked permanently closed on Google Maps are dropped automatically before scoring, so you never waste an outreach call on a place that no longer exists.

How it works: no scraping, no LLM

This is the detail that matters most for a technical audience: this Actor is not a Maps scraper. It expects you to already have place objects (from something like Google Maps Scraper) and does pure computation on top of them — string checks for real vs. social-media-only URLs, null checks across profile fields, and a percentile calculation against other places in the same input batch. No headless browser, no OpenAI call, nothing that can time out or hallucinate. That's also why it's cheap: pay-per-event pricing is $0.005 per run start plus $0.0015 per scored lead returned. Scoring 1,000 already-scraped places costs about $1.51 on top of whatever the scraper itself charged.

Usage: Apify Console or the API

Option 1 — Apify Console

Run a Google Maps scraper for your target city/category and grab its dataset output (as JSON).
Open Google Maps Lead Priority Scorer in Apify Console, paste that array into the Google Maps places input field.
Optionally set Minimum priority tier to Warm or Hot so you're only ever billed for the leads worth calling.
Click Start. Results come back sorted highest-priority first, downloadable as JSON/CSV/Excel.

Option 2 — `apify call` from the CLI

apify call reverenced_garnet/apify-gmaps-lead-priority \
  --input '{
    "places": [
      { "title": "Lemari Coffee", "placeId": "ChIJv79rmEfzGGARhXlSEd8ceiQ" }
    ],
    "minTier": "Warm"
  }'

Option 3 — Apify API / SDK (chaining two Actors)

A realistic setup looks like this: scrape → score → dataset, all in one script. Here's a minimal Node example using the Apify client that chains a Maps scraper run into this Actor:

import { ApifyClient } from 'apify-client';

const client = new ApifyClient({ token: process.env.APIFY_TOKEN });

// 1. Run a Google Maps scraper for a city/category
const scrapeRun = await client.actor('compass/crawler-google-places').call({
    searchStringsArray: ['coffee shop in Austin, TX'],
    maxCrawledPlacesPerSearch: 200,
});
const { items: places } = await client
    .dataset(scrapeRun.defaultDatasetId)
    .listItems();

// 2. Score those places for lead priority
const scoreRun = await client.actor('reverenced_garnet/apify-gmaps-lead-priority').call({
    places,
    minTier: 'Warm',
    webhookUrl: 'https://your-n8n-instance.example.com/webhook/new-leads',
});

const { items: leads } = await client
    .dataset(scoreRun.defaultDatasetId)
    .listItems();

console.log(`Got ${leads.length} Warm+ leads, top one:`, leads[0]);

The same works in Python with the apify-client package (ApifyClient(token=...), .actor(...).call(run_input=...), .dataset(...).list_items()).

Input schema

Field	Type	Description
`places`	array	Place objects from a Google Maps scraper's dataset output
`minTier`	string	`Hot`, `Warm`, or `Cold` (default) — minimum tier to include in the output
`slackWebhookUrl`	string (optional)	Slack Incoming Webhook URL — posts a run summary
`discordWebhookUrl`	string (optional)	Discord Channel Webhook URL — posts a run summary
`webhookUrl`	string (optional)	Any URL — receives a structured JSON summary (e.g. for n8n/Make)
`notifyOnlyNewOrUpdated`	boolean	Default `true` — only include `NEW`/`UPDATED` leads in notifications

Output fields

{
  "title": "Lemari Coffee",
  "placeId": "ChIJv79rmEfzGGARhXlSEd8ceiQ",
  "priorityScore": 60,
  "tier": "Warm",
  "changeStatus": "NEW",
  "reasons": [
    "No independent website (social-media link or none at all)",
    "No business description"
  ],
  "hasRealWebsite": false,
  "isUnclaimed": false,
  "completenessScore": 70,
  "reviewPercentileInGroup": 25.0
}

Field	Type	Description
`title`	string	Business name
`placeId`	string	Google Maps place ID
`priorityScore`	number	0-100 combined lead-priority score
`tier`	string	`Hot`, `Warm`, or `Cold`
`changeStatus`	string	`NEW`, `UPDATED`, or `UNCHANGED` vs. the previous run on this Actor
`reasons`	array	Plain-English reasons contributing to the score
`hasRealWebsite`	boolean	False if no site, or only a social-media link
`isUnclaimed`	boolean	True if the Google Business Profile is unclaimed
`completenessScore`	number	0-100 GBP profile completeness
`reviewPercentileInGroup`	number	Review-count percentile vs. same city+category peers

One useful, unusual feature for anyone running this on a schedule: changeStatus. Run the Actor again later on the same area and every lead gets tagged NEW, UPDATED, or UNCHANGED compared to the previous run, so you only re-review what actually moved instead of re-triaging the whole list every week.

Use case: building an outbound list for a local SEO agency

Hypothetical workflow: a typical setup for an agency doing outbound prospecting for, say, dentists in a metro area:

Run Google Maps Scraper for "dentist in Denver, CO", get back a few hundred place objects.
Feed that array into this Actor with minTier: "Hot" — you now only pay for and receive the businesses with the strongest combination of no website, unclaimed profile, and thin review count.
Set slackWebhookUrl so the agency's sales channel gets pinged with a summary whenever a run finds new or updated leads.
Schedule the whole pipeline (scraper → scorer) weekly with Apify's built-in Scheduler. Because of changeStatus, week-over-week runs only surface leads that changed, so the team isn't re-triaging the same few hundred businesses every Monday.
Export the dataset as CSV and import into whatever CRM or cold-email tool the agency uses.

The same pattern works for directory sites deciding which unclaimed listings to email about claiming their profile, or freelancers building a target list for a single vertical + city combo before a cold-call sprint.

A word on scope and legality

This Actor deliberately does one thing: turn place data you already have into a priority score. It doesn't scrape anything, doesn't call any external API, and doesn't infer anything with an LLM — which is also why it's fast and cheap. It's also worth being explicit that the presence of a phone number or address on a public Google Business Profile doesn't by itself mean you have consent to cold-call or cold-email that business. If you're using this for outreach, you're responsible for complying with applicable law (GDPR, CAN-SPAM, TCPA, etc. depending on where your leads are).

Try it

The Actor is live on the Apify Store: Google Maps Lead Priority Scorer. If you're already running a Google Maps scraper as part of a lead-gen pipeline, this is a five-minute addition that replaces a manual sorting/filtering step with a single number you can sort by and trust.

DEV Community: orange

I Had an AI Agent Scrape Google Maps Instead of Writing a Scraper. Here's What It Cost.

The setup

The agent runs

The script baseline

Accuracy

What I'd conclude

Can the cost be cut?

What I did not test

Checking If a Business's Google Profile Actually Matches Its Own Website

What it does, and what it doesn't

How it works

Usage

Apify Console

Chaining two Actors with apify-client (Python)

Input

Output

Use case: auditing NAP consistency before a local SEO engagement

A note on scope and responsible use

Pricing

Try it

Turning Google Maps Scraper Output into a 0-100 Lead Priority Score (No Scraping, No LLM)

The problem with single-signal lead lists

How it works: no scraping, no LLM

Usage: Apify Console or the API

Option 1 — Apify Console

Option 2 — apify call from the CLI

Option 3 — Apify API / SDK (chaining two Actors)

Input schema

Output fields

Use case: building an outbound list for a local SEO agency

A word on scope and legality

Try it

Option 2 — `apify call` from the CLI