I planted 370 SEO defects in a fake 400-page site to test an auditor

Logan Bishop — Sat, 24 Oct 2026 17:29:07 +0000

Everything below uses a site I generated. These are test results, not results from anyone's real website.

The idea

A crawl of your own site already holds most of what an SEO metadata audit needs: titles, descriptions, canonicals, language, Markdown (so headings), word counts. Crawling again to check them is a second bill and a second chance to get blocked. So I wrote an Apify Actor that audits the dataset you already have, such as Website Content Crawler output, and never fetches anything.

The hard part of building an auditor is not writing the rules. It is knowing the rules fire when they should, and stay quiet when they should not. I had no real site I could publish results about, so I built a fake one.

The benchmark

A seeded generator produces a synthetic 400-page site in Website Content Crawler's shape: url, metadata.title, a description, a canonical, Markdown text and a status. Every generated page carries a hidden list of the exact issue codes the audit must report, planted on purpose: titles built right at the length limits, a canonical that points at another canonical, groups of pages that share a title, thin pages, broken status codes.

The test passes only if the audit reports exactly the planted issues on every page: nothing missing and nothing extra. It does: 400 of 400 pages match, across 54 distinct rule codes.

On that site the audit reports 370 issues (50 errors, 238 warnings, 82 info), a site score of 94 (grade A), 333 pages graded A and 67 graded B. The top issues:

Issue	Pages
Very thin content	11
Canonical chain or loop	7
Canonical invalid	6
HTTP error status	6
No H1	5

Site-level analysis finds duplicates across pages: 6 groups of duplicate titles, 3 of duplicate descriptions, 3 of duplicate H1s, 2 of duplicate page text and 3 of URL variants. Every page's score lists the points it lost, for example -6 T005 duplicate title (group dt_1, 2 pages) or -15 D001 meta description missing.

What this does and does not prove

It proves the rules do what I wrote them to do, including at the boundaries, and that the scoring adds up. It does not prove the auditor is accurate on real sites. I wrote the generator, the rules and the tests, so this is a self-consistency check, not an independent one. Real crawls will have shapes I did not think of. If a field my adapter expects is missing from your dataset, for example the HTTP status or the Open Graph tags, the checks that need it are skipped and listed in the run summary instead of flagging every page, but I have not yet confirmed those field names against every crawler's current output.

Speed and cost, also on synthetic data

On a laptop, the audit step took about half a second for 10,000 generated pages. In the cloud, a run on 2,000 synthetic pages took 4.0 seconds end to end at 1 GB: loading the dataset about 1.6 s, the audit 0.14 s, writing the results about 0.6 s. Reading and writing the dataset is the slow part, not the auditing.

Two design choices worth copying

Skip, don't guess. If the dataset has no heading data, the H1 rules do not run, and the run summary says why. Flagging "no H1" on every page of a crawl that simply did not save headings would be a false alarm.

Explain every point. Each issue has a code, a message, evidence and a fix, and the score is 100 minus the listed penalties, with caps per category. You can reproduce any score by hand.

Try it

https://apify.com/hiredhandai/seo-metadata-auditor ($1.50 per 1,000 pages, pay per use). The prefilled example audits six inline pages in a few seconds. If you run it on a real crawl and it misses something or flags something wrong, I would like to hear about it.

I'm the author, and I used AI assistance to draft and test this.

I generated 500 messy scraped leads and tried to clean them: what broke

Logan Bishop — Wed, 21 Oct 2026 00:39:35 +0000

Disclosure: I built the Actor mentioned at the end of this post. The test data below is synthetic, and I say so wherever it matters.

TL;DR: on a synthetic 500-row file, the cleaner returned the 400 real businesses, merged the 90 planted duplicates and made no false merges. Getting there took three dedupe fixes (shared inboxes, shared name prefixes, numbered branches) and two deployment fixes (dataset permissions, monorepo bundling).

Scraped lead lists have a reputation for being messy, and everyone nods at that. I wanted numbers, so I built a fixture and tried to clean it with the tool I am writing: an Apify Actor that normalizes, dedupes and scores business records.

This post is about what broke. The headline results are at the end of the first section, but the bugs are the useful part.

The fixture

I did not want to scrape a real site just to test a cleaner, and I did not want to publish someone else's business data. So I wrote a generator. It is deterministic (seeded), and it produces:

400 distinct businesses with unique names, written out as 500 rows
3 different scraper field schemas mixed in the same file: title / emailAddress / phone / website; Company Name / E-mail / Phone Number / URL; and name / emails[] / phones[] / site (with street_address and town)
90 intentional duplicates: a second sighting of an existing business, pushed through a random schema, with a typo in the name, a missing email, or a missing phone and website
noise on top: ALL-CAPS and doubled spaces, tracking parameters, doubled @@, mailto: prefixes, mojibake accents, disposable and mistyped email domains
10 junk rows with almost nothing usable in them

Here is a real duplicate pair from the file (same business, two schemas, one invalid email, one missing website):

{ "Company Name": "  Pioneer  Plumbing ", "E-mail": "anna.k@@pioneerplumbing16.co.uk",
  "Phone Number": "+44 2054019332", "URL": "https://pioneerplumbing16.co.uk#contact",
  "Full Address": "5449 Market St, London", "City": "London", "Country": "gb", "Industry": "Plumber" }
{ "name": "  Pioneer  Plumbing ", "emails": ["ANNA.K@PIONEERPLUMBING16.CO.UK"], "phones": [""], "site": "",
  "street_address": "5449 Market St, London", "town": "London", "country": "gb", "type": "Plumber" }

The merged record keeps the valid email from the second row and the phone and website from the first.

The expected output for the 500-row file is easy to state because I built it: 500 minus 90 duplicates minus 10 junk rows is 400 records. That gives me something a script can assert on.

The caveat, up front: this is a synthetic file that I wrote, using assumptions I also hold when writing the matcher. A result of "zero errors" on it tells me the code is consistent and guards against regressions. It does not tell you how the tool behaves on your Google Maps export. Treat everything below as a development story, not a benchmark.

With that said, the final numbers on the fixture:

Measure	Result
Records returned	400
Duplicates merged	90
False merges	0
Missed duplicates	0
Run time on Apify	about 2 seconds

Getting to "zero false merges" is where the work was.

Bug 1: shared email addresses merged unrelated businesses

My first blocking keys were the obvious ones: website domain, normalized phone, email address, and name plus city. If two rows share a key, they are candidates for merging.

The email key was a mistake. Plenty of small businesses list a personal gmail.com address, and in a larger list several unrelated businesses will list the same one (a franchise owner, a freelancer who runs three storefronts, a bookkeeper). A few rows also had disposable-domain addresses. Keying on the full address merged all of them into one record.

The fix was to treat an email as a dedupe key only when it is a business address. Free-mail providers and disposable domains are excluded from the key, but the address is still cleaned, validated and kept on the record. The rule is now: a shared info@acmeplumbing.com is evidence of one business; a shared someone@gmail.com is not.

Bug 2: "Red Rock Bakery" and "Red Rock Realty"

For fuzzy name matching I used Jaro-Winkler, which rewards a shared prefix. That is what you want for "Acme Plumbing" versus "Acme Plumbing Co", and exactly what you do not want here. Both names start with red rock, and once two such businesses sit in the same city, the similarity is high enough to merge them: Jaro-Winkler scores red rock bakery against red rock realty at 0.931, just above my 0.93 threshold.

The fix was a word-compatibility rule: after normalizing, if each name has a word the other one lacks, the pair is rejected no matter how high the similarity score is. "Bakery" is not in the other name, "Realty" is not in this one, so they stay separate. A name with only extra words on one side ("Acme Plumbing" and "Acme Plumbing Services") is still a candidate. The rule is small:

// words match if similar enough; any word containing a digit must match exactly
const wordsMatch = (a: string, b: string) =>
  /\d/.test(a) || /\d/.test(b) ? a === b : jaroWinkler(a, b) >= 0.85;

// reject a pair when each side has a word the other side lacks
function wordsCompatible(a: string, b: string): boolean {
  const lacking = (from: string[], against: string[]) =>
    from.some((w) => !against.some((o) => wordsMatch(w, o)));
  const wa = a.split(' ');
  const wb = b.split(' ');
  return !(lacking(wa, wb) && lacking(wb, wa));
}

The follow-up post in this series covers the rule and the similarity numbers in detail.

Bug 3: "Store 1000" and "Store 1001"

Chain businesses are the worst case for fuzzy matching. Branch names differ by one character, so the similarity is very high: Jaro-Winkler scores store 1000 against store 1001 at 0.96. I only caught this one because a 10,000-row synthetic run merged 5,465 records when I expected about 1,000. Two branches in the same city are two different places, and merging them throws away a real lead.

The fix is the digit check in the snippet above: numbers in a name must match exactly. If the digit sequences differ, the pair is distinct. This is crude and it is correct far more often than it is wrong. The cost is that a true duplicate can survive when two sources disagree on the number itself, and I would rather leave a duplicate than silently delete a branch.

Bug 4: the Actor could not read the dataset

This one is not about data quality. The input takes a dataset ID so the Actor can be chained after any scraper. It worked locally. The first run on the platform, which uses limited permissions, failed with a 403 because it could not read a dataset it had not created.

Actors running with limited permissions cannot read arbitrary datasets by ID. The platform expects access to be granted through the input. The fix was to declare the dataset input as a resource picker in the input schema, so the user picks the dataset in the Console and the run is granted access to it.
If you build any Actor that consumes another Actor's output, test it under limited permissions before you ship. It cost me a debugging session.

Bug 5: monorepo plus `apify push`

The logic lives in a shared packages/core package (kept free of Node-only APIs so it can also run in a Cloudflare Worker later), and the Actor lives in a sibling folder. apify push uploads the Actor folder and builds it on the platform. The platform build does not know about my workspace layout, so the shared package cannot be resolved from the Actor folder alone.

The fix was to bundle the Actor and its core code into a dist build before pushing, so the uploaded folder is self-contained. There was a second catch: apify push skips anything matched by .gitignore, and dist was ignored, so the first build died with Cannot find module '/usr/src/app/dist/main.js'. A !dist/ line in .actorignore forces it back in. It is a build chore, not a design problem, but it is the kind of thing that costs an hour the first time.

Scale and cost

The 500-row run is a correctness test. For scale I ran 10,000 records with live DNS checks on every email domain on Apify. That took about 61 seconds. (The email domains in that test were synthetic and mostly do not exist, so real lists can be faster or slower depending on how quickly the domains answer DNS.) The measured platform cost was about $0.005 per 1,000 records returned, so compute is a rounding error next to the price.

The price I set is $1.50 per 1,000 cleaned records, pay per event, and merged duplicates are not charged. On the fixture that means 400 records, which is about $0.60. I am telling you this so the arithmetic is checkable, not to argue it is cheap or expensive for your situation.

What I would do differently

Write the false-merge tests before the matcher. All three merge bugs were cases I could have listed on day one: shared inboxes, shared prefixes, numbered branches.
Make every merge explainable. Each output record carries a dupeGroupId and each score carries a reasons list, which made these bugs visible instead of silent.
Test on a messier fixture than you think you need. Mine had three schemas and it still did not cover everything real scrapers produce.

If you want to try it

The Actor is called Lead Data Cleaner, Deduper & Scorer. It cleans, dedupes and scores records from any Apify dataset or pasted JSON. It does not scrape, send email or probe mail servers, and it stores nothing after the run. The email check is a DNS lookup of the domain only.

It is live on Apify Store at https://apify.com/hiredhandai/lead-data-cleaner. Questions or bug reports: leadcleaner@lbishop.app. I am the author, and I am also on X as @lbishopdev.

If you have a type of messy record that breaks it, I would like to see the (anonymized) shape of it.

DEV Community: Logan Bishop