# Business Opportunity Finder (`nordapi/business-opportunity-finder`) Actor Find businesses that have a problem you may be able to solve. Discover potential website, booking, contact, mobile, and digital presence opportunities from real businesses. - **URL**: https://apify.com/nordapi/business-opportunity-finder.md - **Developed by:** [Nord](https://apify.com/nordapi) (community) - **Stats:** 1 total users, 0 monthly users, 0.0% runs succeeded, 1 bookmarks - **User rating**: No ratings yet ## Pricing $10.00 / 1,000 business opportunity founds This Actor is paid per event. You are not charged for the Apify platform usage, but only a fixed price for specific events. Learn more: https://docs.apify.com/actors/running/actors-in-store.md#pay-per-event ## What's an Apify Actor? An Actor is a serverless cloud program that runs on the Apify platform. It has two run modes. In Batch mode, an Actor accepts a well-defined JSON input, performs an action which can take anything from a few seconds to a few hours, and optionally produces a well-defined JSON output, datasets with results, or files in key-value store. In Standby mode, an Actor provides a web server which can be used as a website, API, or an MCP server. Apify vocabulary and the platform model are defined once, in the agent quickstart at https://apify.com/agents.md. ## How to integrate an Actor? If asked about integration, you help developers integrate Actors into their projects. You adapt to their stack and deliver integrations that are safe, well-documented, and production-ready. Do not guess an integration path. Every one of them is in the agent quickstart at https://apify.com/agents.md: the Apify MCP server, Agent Skills with the Apify CLI, the JavaScript and Python clients, the REST API, and the account-free path for an agent with no human to sign in. It also carries the rule on stating cost before the first paid run. For examples already wired to this Actor's own input schema, see the [API](#api) section below. Each client library has reference documentation the quickstart does not restate: [JavaScript/TypeScript](https://docs.apify.com/api/client/js/docs.md) (`npm install apify-client`) and [Python](https://docs.apify.com/api/client/python/docs.md) (`pip install apify-client`). # README ## Business Opportunity Finder **Find businesses that have a problem you may be able to solve.** Business Opportunity Finder is a research and lead-discovery tool for agencies, consultants, and service providers who help local businesses improve their online presence. Give it a search — e.g. "dentists" in "Amsterdam", or "restaurants" in "Utrecht" — and it finds real local businesses, analyzes their websites, and surfaces **observable, evidence-backed digital-presence gaps**: a restaurant with no visible way to book a table, a dentist with no HTTPS or contact form, a business with no detectable website at all. Every result comes with the underlying evidence, not just a score — you decide which gaps are worth a closer look. **What this tool does not claim:** - It does not guarantee leads, sales, or customers. - It does not guarantee that any single result is accurate — it reports observable evidence, not verified facts about a business's internal situation. - It does not know that a business "needs" a particular service — it only reports what it could and could not detect on that business's website. - It does not claim that every detected gap is commercially valuable to pursue. - It does not claim a business has no website just because none was found in discovery — see "What this product is / is not" and "Known limitations" below. ### What it does 1. **Finds** local businesses matching a search query and location, via a third-party Google Maps discovery Actor. 2. **Analyzes** each business's candidate website — one HTTP request, homepage only — for signals like HTTPS, contact info, booking links, and social presence. 3. **Verifies** whether that website actually belongs to the business, rather than being a directory or social-media page mistaken for one. 4. **Calculates** two deterministic, rule-based scores from the observed facts: a digital-presence score and an opportunity score. 5. **Optionally qualifies** higher-scoring businesses with an LLM (Anthropic Claude) for a qualitative second opinion — this step can never change the deterministic scores computed in step 4. 6. **Returns** one structured result per business with the underlying facts, the deterministic scores and reasons, and (if run) the LLM qualification, so the evidence behind every result is visible. ### Example use cases People and teams who might use this tool's output as a starting point for their own research or outreach — these are possible **uses of the output**, not guaranteed outcomes: - **Web design agencies** looking for businesses with an outdated, unreachable, or missing website. - **Booking / appointment software providers** looking for businesses with no detected online booking capability. - **SEO and digital marketing agencies** looking for businesses with weak metadata, missing HTTPS, or other observable digital-presence gaps. - **CRM / contact-form solution providers** looking for businesses with no detected contact form or contact information. - **Mobile / web optimization services** looking for businesses whose sites are missing basic signals like a mobile viewport tag. ### Example input ```json { "query": "dentists", "location": "Amsterdam", "maxResults": 20 } ``` Only `query` and `location` are required. When run as an **Apify Actor**, `maxResults` can go up to **200**. This is a different, independent setting from the optional **MCP interface** described further down, whose own `maxResults` is capped at **35** — do not confuse the two. See "Input" below for the full Actor input example and every configurable field. ### What you get Each result keeps three kinds of information separate, and never blends them: - **Facts** (`business`, `website`, `signals`) — what was actually discovered and observed: business details from the discovery source, plus website facts and signals from a single fetch of its homepage. - **Deterministic analysis** (`digitalPresence`, `opportunity`) — two rule-based scores computed from those facts using fixed, documented weights, with no AI involved. `opportunity.reasons[]` lists exactly which observed facts contributed to the score, and `website.verificationReasons[]` explains why a website was (or wasn't) judged to belong to the business. - **Optional LLM qualification** (`llmQualification`) — a separate, qualitative second opinion from Claude, run only for higher-scoring businesses, that can never change the two scores above. `llmQualification.result.reasons[]` explains its judgment in plain language. See "Explaining the scores" and "LLM opportunity qualification" below for what the scores actually measure, and "Output" for the full field-by-field example. ### Example workflow A web design agency wants to find dentists in Amsterdam who might benefit from a website refresh. They run this Actor with: ```json { "query": "dentists", "location": "Amsterdam", "maxResults": 20 } ``` For each business in the results, they look at: - `opportunity.score` and `opportunity.tier` — a quick, deterministic read of how many observable gaps were found. - `opportunity.reasons[]` — exactly which gaps were detected (e.g. no HTTPS, no contact form) and the evidence behind each one. - `website.verificationReasons[]` — why the analyzed website was (or wasn't) judged to actually belong to the business, so they don't waste time on a directory or social-media page mistaken for a site. - The underlying `business`/`website` facts — to sanity-check a result before spending any time on it. They use this to build a shortlist of businesses worth a closer look — not a finished list of leads ready to contact. ### What this product is / is not **This is:** - A business discovery and website/digital-presence analysis tool. - A deterministic, rule-based opportunity-scoring system. - An optional, clearly-separated LLM qualification layer. - A structured research output for a human to review. **This is not:** - A sales automation platform. - A CRM or contact-management system. - A guaranteed lead generator. - A buyer-intent or purchase-readiness database. - A full website crawler — analysis is homepage-only. - A guarantee that any business will purchase any service. ### Explaining the scores - **`digitalPresenceScore` (0–100)** reflects how many observable digital-presence signals were found on a business's own, verified website (HTTPS, contact info, booking links, social links, and so on). It is a count of positive signals actually observed — not a measure of design quality, popularity, or revenue. - **`opportunityScore` (0–100)** reflects how many observable gaps were found — missing signals that could represent an opportunity for someone offering a related service. It is not a prediction of whether a business wants that service, will respond to outreach, or would ever buy anything. - Both scores are **deterministic**: the same input always produces the same score, using fixed rules this project defines and documents (see "Scoring model" below). They are not machine-learning predictions and not measures of buying intent or revenue potential. - **Tiers** (`opportunity.tier`: `low` 0–24, `medium` 25–49, `high` 50–100) are thresholds this project chose to group scores for convenience. They are project-defined ranges, not an industry standard — a `low`-tier result is not "bad" and a `high`-tier result is not a guaranteed opportunity. ### Status: MCP interface available In addition to the Apify Actor below, the same pipeline is also exposed as an MCP server with one tool, `find_business_opportunities` — see "MCP interface" further down for the (optional, secondary) details. The Actor itself is unchanged either way. ### Actor status: production-hardened The full pipeline is real end-to-end: discovery → website analysis → relevance verification → deterministic scoring → LLM qualification. The LLM is a qualitative layer on top of the deterministic score — it can never modify `digitalPresenceScore`/`opportunityScore`/`websiteType`. Phase 8 audited and hardened this pipeline for external Apify users: a per-business error boundary so one bad record can't lose an entire run, a synced Actor input schema, real bounded concurrency, and a few output fields that were computed internally but never actually surfaced. #### Pipeline stages (technical) - Discovers real local businesses for a `query`/`location` via a reputable third-party Google Maps scraping Actor (we do not scrape Google Maps ourselves). - Fetches each business's candidate website (one HTTP GET, homepage only) and extracts facts: reachability, HTTPS, title/meta description, contact info, booking/appointment links, social links, and more. - Verifies whether that candidate URL is actually the business's own site versus a third-party directory or social/profile page, so evidence is never misattributed. - Computes two **deterministic, reproducible** scores from those facts — `digitalPresenceScore` and `opportunityScore` (with a tier and named reasons) — from fixed weights, no LLM involved. - Optionally sends businesses that clear a configurable opportunity-score threshold to an LLM (Anthropic Claude) for a qualitative, evidence-only judgment (`qualified`, `opportunityType`, `confidence`, `summary`, closed-vocabulary `reasons`) — a separate, clearly-labeled layer that can never change the deterministic numbers. - Produces one Dataset row per business with facts, deterministic scores, and (if run) the LLM judgment kept in distinct, never-conflated fields. #### Explicit scope exclusions (technical) - It does **not** prove a business has no website when discovery returns none — `websiteType: "not_provided"` means "not found by this discovery source," never "confirmed absent." - It does **not** guarantee a detected opportunity reflects a real commercial need — both the deterministic score and the LLM judgment are evidence-based signals for a human to review, not a sales guarantee. - Website analysis is **homepage-only and HTTP-only**: no crawling, no JS execution. A JS-rendered single-page app's real content, or a booking widget on a different page, may not be seen. `false`/absent signals mean "not detected on the fetched page," not "confirmed absent from the whole site." - LLM qualification is **probabilistic**, not a fact extractor. It only reasons over the same evidence already computed deterministically, but its wording and judgment can vary between runs even on identical input (see "Known limitations" for an observed instance of residual interpretive language). - It is **not** a general-purpose Google Maps scraper — fields not relevant to identifying a digital opportunity (photos, opening hours, full review text, etc.) are intentionally not collected. - No MCP integration, no database, no dashboard/UI, no browser-based (Playwright) analysis, no competitor analysis, no billing/auth — out of scope for this Actor as currently built. ### Website relevance verification A discovery source can return a URL that is NOT the business's own website — observed directly in Phase 5's "Medical Center Gaffar" case, where the "website" field pointed to a third-party directory/citation page (`nlzoommap.org`) whose title was literally *"NLmapNew.com — Local Business Directory in the Netherlands"*. Scoring that page's facts as if they were the business's own would have produced a misleading result. `verifyWebsiteRelevance` (`src/core/verification/websiteRelevanceVerifier.ts`) runs after website analysis (it needs the fetched page's facts — final URL, title — so the fetch must happen first, even though some framings of this pipeline put verification "before" analysis) and classifies the candidate URL as one of: - `business_website` — likely the business's own site - `third_party_directory` — a listing/citation/aggregator page - `social_or_profile` — a social network or profile-based platform - `unknown` — genuinely ambiguous; NOT "probably not" - `not_provided` — no candidate URL existed to classify This is explicitly **not proof of legal ownership** — just whether the page is appropriate evidence for judging the business's own digital presence. Confidence (`high`/`medium`/`low`) describes confidence in the *classification*, never business quality. **Classification logic, in priority order:** 1. **Domain-list match always wins**, even over a business-name match in the page content (`src/config/knownWebsitePlatforms.ts`, matched against the normalized *registrable* domain — see below, never a raw hostname substring). A directory or social page mentioning the business name is still a directory/social page — this is what makes `third_party_directory`/`social_or_profile` correctly fire even when the business name appears on the page. This check runs regardless of whether the fetch itself succeeded (a known social/directory domain that timed out is still classified by its domain). 2. A generic directory-ish title (e.g. "business directory", "bedrijvengids") on a domain we haven't explicitly listed — a content-based fallback. 3. Otherwise, accumulate weak identity evidence: `PAGE_TITLE_MATCH` (+40), `BUSINESS_NAME_MATCH` in the meta description (+20), `PHONE_MATCH` (+35, comparing the last 9 digits so country-code/formatting differences don't block a match), `ADDRESS_MATCH` (+25, Dutch postal code), `REDIRECTED_TO_BUSINESS_DOMAIN` (+10) or `FINAL_DOMAIN_MATCH` (+5, same domain throughout). Score ≥60 → `business_website`/`high`; ≥30 → `business_website`/`medium`; otherwise → `unknown`/`low`. A `BUSINESS_NAME_MISMATCH` reason is added (not a rejection) when title/ meta description exist but share no tokens with the business name. **Domain normalization**: the `psl` package (public-suffix-list based) extracts the true registrable domain (`www.example.co.uk` → `example.co.uk`), so `notfacebook.com` and `facebook.example.com` are never confused with `facebook.com` — verified directly in tests. Domain-list configuration is intentionally small and NL/local-business-focused (Dutch directories like `cylex.nl`, `goudengids.nl`; social platforms like Facebook, Instagram, Yelp, Tripadvisor), not an exhaustive global blacklist — extend it as new false positives are observed. **Identity evidence** (name/phone/address matching) required extending `WebsiteSignals` with `detectedPhoneNumbers`/`detectedPostalCodes` — the actual matched substrings, not just the Phase 4 booleans — since comparing against `business.phone`/`business.address` needs the real value. ### Scoring model Two intentionally separate, deterministic scores — never derived from each other (`opportunityScore` is never `100 - digitalPresenceScore`). All weights live in `src/config/scoringWeights.ts`, documented inline; nothing scoring-related is hardcoded elsewhere. **Phase 6 change**: content-based facts (HTTPS, title, contact form/page, booking, social links) are only ever scored as evidence of the business's OWN digital presence when `website.websiteType === "business_website"`. A `third_party_directory`/`social_or_profile`/`unknown` classification gets a fixed, small **neutral** `digitalPresenceScore` of **15** instead — high enough to reflect "they clearly have *some* web presence" but far below what a verified site's actual facts could earn, and low enough to never imply we assessed their own site's quality. This applies even if the fetch itself failed (a known social/directory domain that timed out still gets the neutral 15, via the domain classification alone). **`digitalPresenceScore` (0–100)** — purely additive from POSITIVE, directly-observed facts on a *verified* business website (reachable, HTTPS, title, meta description, viewport, phone/email/address, contact page/form, social links, booking capability), capped at 100. There are no separate penalty weights: a fact that wasn't observed simply contributes nothing, which already produces a low score without subtracting anything — this is how double-counting is avoided by construction. When the website couldn't be meaningfully analyzed (unreachable/timeout/invalid URL/non-HTML/too large), wasn't found in discovery at all, or wasn't verified as the business's own site, the score is a single small fixed value for that category (0 for "not found", 5 for a confirmed technical failure, 10 for "responded but unanalyzable", 15 for "unverified/ third-party") — never a sum of "missing metadata" penalties for a page we never actually got to see, or shouldn't be attributing to this business. **`opportunityScore` (0–100)** — additive from structured, evidence-only reasons (`{code, weight, evidence}`), in three mutually-exclusive groups: 1. **Website availability** (at most one fires): `WEBSITE_UNREACHABLE` (40 — the most *confirmed* problem: a specific URL was tried and failed), `WEBSITE_NOT_FOUND_IN_DISCOVERY` (35 — deliberately *below* unreachable, since a missing URL in the discovery source is the *least* certain of these signals and never implies the business has no website anywhere), `WEBSITE_TIMEOUT` (30), `WEBSITE_INVALID_URL` (20), `WEBSITE_NON_HTML_OR_UNANALYZABLE` (12). 2. **Unverified website identity**: `THIRD_PARTY_URL_ONLY` (10 — deliberately small; the *only* evidence found was a directory/social page, not a verified business-owned site. Never inflated into a large score merely because a directory page was discovered — see "Avoid turning uncertainty into a sales lead" below. When `websiteType` is `"unknown"` with a successfully analyzed page, no reason fires at all — genuinely ambiguous evidence contributes nothing either way.) 3. **Content-based** (only when `websiteType === "business_website"` AND `analysisStatus === "success"`): `NO_BOOKING_OR_APPOINTMENT_DETECTED` (20), `HTTP_ONLY_NO_HTTPS` (12), `NO_CONTACT_FORM_DETECTED` (8), `NO_CONTACT_INFO_DETECTED` (8 — one consolidated reason for phone+email+address all missing, not three), `NO_CONTACT_PAGE_DETECTED` (6), `NO_SOCIAL_LINKS_DETECTED` (5), `MISSING_META_DESCRIPTION` (5), `MISSING_VIEWPORT_META` (5), `WEAK_OVERALL_WEBSITE_PRESENCE` (10, when digitalPresenceScore < 30). Rating and review count are **never** used as scoring inputs — verified in both unit tests and the real integration test (identical website evidence with a 2.1★/3-review business and a 4.9★/900-review business produces the exact same `opportunityScore`). They're passed through as context in `business.googleRating`/`googleReviewCount` for a human or a future LLM to weigh, per the explicit instruction not to invent a relationship between popularity and digital weakness. **Tiers** (`opportunity.tier`): `low` 0–24, `medium` 25–49, `high` 50–100. Chosen around evidence *convergence* rather than raw severity: a single strong standalone signal (e.g. `websiteUnreachable` alone = 40) lands in `medium` — serious, but one data point — while `high` requires either the single most-confirmed signal or multiple converging content gaps. These are our model's ranges, not an objective severity scale. ### LLM opportunity qualification **In plain terms**: LLM qualification is optional and only runs for businesses whose deterministic `opportunityScore` already clears a threshold — deterministic scoring always happens first, for every business, whether or not the LLM ever runs. The LLM cannot override, adjust, or replace any deterministic score; it can only add a separate, clearly-labeled qualitative opinion (`llmQualification`) reasoned over the same evidence already computed deterministically — never over raw website content, and never disclosed here as internal prompt text. Its output is validated against a fixed structure before being trusted. If the LLM call fails or times out, that business is not penalized or treated as a negative result — its deterministic scores stand unaffected, and `llmQualification.status` simply records `"failed"` or `"not_run"`. Answers a different question than the deterministic score: not "how many observable opportunity signals exist" (already computed) but "given this evidence, does this look like a credible opportunity worth a human looking into?" The LLM is a qualitative layer, never the source of truth for facts, and can never modify `digitalPresenceScore`/`opportunityScore`/ `opportunityTier`/reason codes/`websiteType` — those are already final by the time qualification runs (`runPipeline`: discovery → analysis → verification → **scoring** → **qualification**). **Evidence bundle** (`buildOpportunityEvidence`, `core/ports/llmProvider.ts` `OpportunityEvidence`): a compact, deterministic JSON object — business identity (name/category/address/rating/reviewCount/phone), verified website facts (candidateUrl/finalUrl/websiteType/verificationConfidence/ title/metaDescription/https/reachable/statusCode/language), the ten boolean signals, and the deterministic digitalPresenceScore/ opportunityScore/tier/reasons. Never raw HTML, never a URL to fetch, never unstructured discovery metadata (e.g. `googleMapsUrl` is excluded). Same inputs always produce the same bundle. **Output schema** (`LLMQualificationResultSchema`, `core/entities/llmQualification.ts`): `qualified: boolean`, `opportunityType` (one of `website`/`booking`/`conversion`/`contact`/ `mobile`/`digital_presence`/`unknown` — the LLM's chosen *primary* category, not one per deterministic reason), `confidence` (`high`/ `medium`/`low` — confidence in the classification, never business quality), `summary` (≤500 chars), `reasons` (≤5 `{code, evidence}` entries). Enforced via Anthropic's native structured-output support (`output_config.format: {type: "json_schema", ...}`), then re-validated with the same Zod schema — never trusted blindly. **Phase 7.1**: `reasons[].code` is constrained to the closed `OPPORTUNITY_REASON_CODES` vocabulary (`core/entities/opportunityReasonCodes.ts` — the same single source of truth the deterministic scoring service itself uses) plus one `OTHER` fallback, enforced at the JSON-Schema level (the model cannot even generate a code outside this `enum`), not just via Zod afterward — see "Reason-code vocabulary" below. **Status envelope** (`LLMQualificationSchema`): `{status: "not_run" | "success" | "failed", result, notRunReason, failureReason, failureDetail, modelUsed, usage}`. All three states are structurally distinct — a missing qualification is never just `null`. `failureReason` is one of `timeout` / `provider_error` / `invalid_output` / `configuration_error`. `usage` (`{inputTokens, outputTokens}`, Phase 7.1) holds real token counts from the Anthropic API response, summed across the initial attempt and the retry if one happened — populated only on `"success"`, and never an estimate. **Prompt** (`src/config/llmQualificationPrompt.ts`, versioned): explicitly instructs the model that it is a qualification layer and not a fact extractor, to use only supplied evidence, never infer missing information as negative (`websiteType: "unknown"` → "could not be verified", never "poor website"; no candidate URL → "no website URL was returned by the discovery source", never "no website"), never modify the deterministic scores, treat a `third_party_directory`/`social_or_profile` page as NOT the business's own site, describe a business-name mismatch neutrally ("appears associated with a differently named practice") without calling it fraud/a rebrand/an error, and never invent an opportunity from rating, review count, category, location, domain age, tech stack, or an analyzer failure. **v2 (Phase 7.1)** additionally forbids: generic claims about what a business "needs", speculation about customer behavior, assuming a feature matters merely because it's common in an industry, and unsupported sales/marketing advice — added after real, observed drift in Phase 7's live integration test (see "Known limitations" below). **Reason-code vocabulary** (Phase 7.1): before this, the LLM would occasionally invent its own reason codes (e.g. `DIGITAL_PRESENCE_SCORE_ZERO`) instead of reusing the deterministic ones. Fixed at three layers: (1) the Anthropic structured-output schema's `enum` on `reasons[].code` — the model structurally cannot output a code outside the list; (2) Zod (`LLMQualificationReasonSchema`/`OpportunityReasonSchema` both import the same `OpportunityReasonCodeSchema`/`LLMReasonCodeSchema`) as defense in depth; (3) the prompt explicitly lists every allowed code (generated from `OPPORTUNITY_REASON_CODES` at module load, so it can never drift out of sync) and states the `OTHER` fallback to use instead of inventing one. **Gate** (cost control): the LLM is only called when `opportunityScore >= llmQualificationThreshold` (Actor input, default **25**) — deliberately the same low/medium tier boundary used for `opportunity.tier`, so the gate and the tier system tell a consistent story: below it, deterministic evidence is too thin for a qualitative pass to add anything; from "medium" up, there's at least one substantial signal (or several converging weak ones) worth a second look. A verified, feature-complete `business_website` naturally never crosses the gate. **Retry**: at most 1 retry, and only for malformed/invalid output (bad JSON, or JSON that fails the Zod schema) — the retry resends the conversation with a corrective note. Transport-level failures (timeout, rate limit, auth, server error) are classified and thrown immediately, never retried. One real, live-discovered constraint: Anthropic's structured-output JSON Schema support rejects `maxItems` on array types (`400: property 'maxItems' is not supported`) — fixed by dropping that keyword from the API-level schema and relying on the Zod schema (`.max(5)`) downstream for that constraint instead. **Provider**: `AnthropicLLMProvider` (`src/providers/llm/`) is the only concrete `LLMProvider` implementation; the port itself has zero Anthropic dependency, so a different vendor could be swapped in without touching `core/`. Model/temperature/timeout/max-output-tokens are all Actor input fields, never hardcoded. A `BadRequestError` specifically about `temperature` (some newer models reject it — see the SDK's own deprecation note) triggers one transparent retry without that parameter. The API key is read from `ANTHROPIC_API_KEY` (`.env`-only, never logged); if it's unset, the Actor skips wiring the provider entirely and reports `qualification` as not-implemented at the pipeline level, rather than failing every qualifying business individually. ### Website analysis: how it works One GET request per website, HTTP-only — no Playwright, no JS execution. - **Facts vs. signals vs. status** are three separate concepts: `website.analysisStatus` (`success` / `not_provided` / `invalid_url` / `unreachable` / `timeout` / `non_html_response` / `response_too_large` / `error`) says what happened when analysis was attempted; `website.*` holds directly observed connectivity/metadata facts (status code, final URL after redirects, HTTPS, content type, response time, title, meta description, canonical URL, language); `signals.*` holds deterministic pattern matches (booking/appointment links, contact info, social links). **When `analysisStatus` isn't `"success"`, every signal is `null`** — absence of evidence is never presented as evidence of absence. A business with no website URL at all gets `"not_provided"`, not an error. - **Conservative-by-design heuristics** to avoid false positives: `hasBookingLink`/`hasAppointmentLink` only match a term (English: book, booking, appointment; Dutch: boek, reserveren, afspraak) in an anchor's **text or href** — never in body prose, so an article that merely mentions "appointment" doesn't count. `hasOnlineBooking` is a separate, stronger signal requiring a link to a known third-party booking platform (Calendly, Doctolib, Treatwell, SimplyBook, Booksy, ...). Phone/email detection prefers authoritative `tel:`/`mailto:` links over body-text regex matching, strips `