How to Verify Facebook Page Records in a Local Business Directory

Tool setup and control check

Replace the default two-Page sample list with one intended known public Page URL in startUrls for your pilot run.

The tool build is 0.1.24. It accepts startUrls with one to one thousand known public Page or profile URLs, not search pages or city keyword discovery. One row is one attempted input.

The output metrics include requestedChannels, acceptedProfileInputs, rejectedInputs, datasetRows, usefulRows, billableRows, nonUsefulRows, and statusCounts. Row fields include input, channelId, pageId, channelUrl, handle, displayName, alternateName, profileType, description, category, website, detectedLinks, detectedEmails, phone, email, address, profileTabs, status, statusReason, observedAt, and isBillable. Missing fields are null. channelId and legacy or delegate pageId are distinct identity values and can differ.

A control check on NASA returned matched IDs, status ok, a description, and two detected Facebook section links. Website, phone, email, and address were unavailable. This proves optional fields can be unavailable in that control only.

Directory creation and verification actions

1. Define the directory purpose and required fields before collecting. Use a known source list of intended businesses with local row IDs and where each URL came from. City search is outside this tool. Manual discovery is an explicit prerequisite, not a promised feature.
2. Test one intended public Page. Check channelId, pageId, channelUrl, displayName, profileType, status, and statusReason against the source. A returned identity alone can be useful even when optional About fields are hidden. Do not match by name alone when two businesses share a name.
3. Preserve source rows and time. Store profile IDs as strings and keep legacy or delegate Page ID separately. Deduplicate verified identity observations without dropping the input-to-source list.
4. For each required field record source_available, unavailable, or needs_manual_check. Keep website distinct from detectedLinks. An About or photos Facebook link is a profile section, not an external business website. detectedEmails and detectedLinks are unverified clues, not a complete set of business contacts.
5. If the directory requires city service area or an external website, inspect a matching public business source manually and record evidence, source, and time in separate enriched fields. Do not overwrite null Actor address with a guessed city from a handle. The tool does not do this linked site check.
6. Define directory row readiness for the stated purpose. For example, an identity index needs matched identity; a contact directory also needs an inspected public contact route; a city business list additionally needs supported local relevance. Keep each rule explicit. Missing optional data is not proof that the business lacks that attribute.
7. Split records into ready, needs_review, and unavailable_target. Count matched identities, available fields, and ready records separately. A failed source request is not an empty successful business record. Keep source status reasons so a later retry can be scoped.
8. Export the useful directory with its readiness reason and evidence links. Refresh observations when needed rather than assert the tool supplies past history. This guide does not send outreach or certify businesses.

Original fiction example and table

The following text is original fiction. A fictional cleaning business directory has four intended Pages.

Three matched identities do not yield three ready records. There is one ready record, two needs review or out of scope records, and one unavailable target. The exact rules exclude B4 from the city list based on manual local evidence, not guesses from the Page name. Field availability for the three matched rows is one of three for website and one of three for returned address in this fiction. Unavailable target B3 is reported separately. Do not use these fractions as real tool success rates.