When I started my first directory, I budgeted my time the way most people would: mostly for building the website. Pages, search, design, deployment. I figured listings would be the easy part, something I’d knock out in a weekend once the site itself was ready.
Across four directories and well over 500 published listings later, I can say confidently that assumption was backwards.
The website has never been the bottleneck. The data has, every time, in a slightly different way. This is what I got wrong about listing data on my first couple of builds, and what I actually do differently now.
The mistake underneath all the other mistakes
If there’s one root cause behind almost everything I’d change, it’s this: I treated listing data collection as a task to finish, not a system to run.
A task has a start and an end. You import a batch, you’re done. A system runs continuously, catching the business that closed last month, the duplicate that snuck in from a second data source, the listing that’s been sitting with three enriched fields when it should have twelve.
Every specific mistake below is really a version of the same thing: I planned for a finish line that doesn’t exist.
Mistake #1: Importing before deciding what a “complete” listing looks like
On my earliest builds, I imported basic records first (name, address, phone, category) and told myself I’d add the good stuff (credentials, service details, specialties, whatever made a listing actually useful) once the site was live.
That plan sounds efficient. It isn’t. Retrofitting a new field onto listings that already exist is a completely different job than collecting that field during the initial import.
During import, you’re already looking at the source data with that business open in front of you.
Retrofitting means going back to hundreds of records one at a time, re-researching businesses you’ve already moved past mentally, and building a new enrichment pass that has to check which records already have the field and which don’t.
What I do now: before I import a single row, I finalize the full listing schema, every field I plan to eventually show, not just the ones I’ll launch with.
I still populate them in priority order (basic info first, enrichment layered in over following weeks), but the schema itself doesn’t change after import starts.
Deciding the shape of a complete listing is a five-minute conversation before you have any data. It’s a multi-week cleanup project after.
Mistake #2: Trusting a data source more than it deserved
Every niche has an obvious first place to pull business data from, and in my experience the obvious source is never as clean as it looks.
Duplicate entries under slightly different business names. Businesses that closed a year ago and never got removed. Phone numbers and addresses that were correct when the source was compiled and aren’t anymore.
The pattern I’ve noticed across every niche I’ve built in: a generic, broad business-data source gets you volume fast, and gets you a meaningful error rate along with it.
A narrower, authoritative source specific to the field (a licensing board, a professional association, an industry-specific registry) gets you far fewer raw records, but the ones you get are usually current and real.
The second kind of source takes longer to find and is often more annoying to work with (less structured, sometimes literally a PDF list), but it’s worth the extra effort every time I’ve compared the two.
What I do now: I don’t fully trust any single source. I treat the first import as a draft, not a dataset, and I run an explicit verification pass (is this business still operating, is this the correct current information) before anything goes live.
That verification pass is not optional, and it’s not fast, but it’s much cheaper than discovering six months post-launch that a chunk of your directory is dead weight.
Mistake #3: Chasing the count instead of the quality
It’s tempting to treat listing count as the headline metric, because it’s the easiest one to point to. “500 listings” sounds like a milestone.
But a directory with 500 listings where 80 are duplicates, 40 are closed businesses, and most of the rest have three fields filled in is a worse product than a directory with 300 listings that are all real, current, and genuinely enriched.
I’ve come to believe this is one of the most common traps in directory building specifically, because it’s so easy to measure the wrong thing. Raw count is visible immediately. Verified quality only shows up in whether users trust the site and whether businesses want to be listed on it, both of which take time to observe.
What I do now: I track verified, enriched listings as the real number, not raw imports. If a listing hasn’t cleared verification or has fewer than a handful of the fields that actually differentiate it from a basic Google Business Profile, I don’t count it as done, even if it’s technically live on the site.
Mistake #4: Treating enrichment as a pre-launch task instead of an ongoing one
On my first build, I tried to fully enrich every listing before launch, which meant launch kept slipping while I chased diminishing returns on records I’d already gotten most of the way there.
On a later build, I overcorrected and launched with too many bare-bones listings, assuming I’d circle back, and then didn’t circle back fast enough because nothing was forcing me to.
The fix wasn’t picking one extreme. It was building enrichment into a weekly rhythm from day one: a short, recurring review of which listings need new businesses added, which need enrichment, which have gone stale, and which look like duplicates or dead businesses.
Fifteen to twenty minutes, every week, forever. That cadence has done more for data quality across my portfolio than any single big cleanup push ever has, because it catches problems while they’re small instead of letting them accumulate into a project.
What I do now: listing data quality isn’t a phase I complete before launch. It’s a permanent line item in my weekly operating routine, treated with the same seriousness as checking search rankings or reviewing analytics.
Mistake #5: Trusting AI-assisted enrichment further than I should have
Because I build with AI-assisted development, it was tempting to let that same speed extend into data work: have the AI draft descriptions, categorize businesses, standardize formatting across records.
Most of that works well and saves real time. Where I got burned was assuming it was reliable for judgment calls it shouldn’t have been making unsupervised, like guessing whether a business still operates based on stale source data, or forcing a business into the closest existing category instead of flagging that it didn’t fit cleanly anywhere.
What I do now: AI handles the mechanical parts of enrichment (formatting, drafting, standardizing) well, and I let it. It doesn’t get final say on anything that’s actually a judgment call about a real business, current status, correct categorization, whether a claim in the source data is trustworthy. Those get a human pass.
The line isn’t “AI versus no AI.” It’s being honest with myself about which parts of this work are mechanical and which are judgment, and not letting the speed of the mechanical parts convince me the judgment parts got easier too.
What I’d actually do differently, in order
If I were starting a fifth directory tomorrow, here’s the sequence I’d follow, informed by all of the above:
- Finalize the full listing schema before importing anything, even fields I won’t populate until later.
- Identify the most authoritative data source for the niche, not just the fastest one to pull from, even if it means more manual work up front.
- Treat the first import as a draft, and run an explicit verification pass before anything goes live, checking that each business is real, current, and correctly categorized.
- Launch with a smaller, fully verified dataset rather than a larger, partially verified one. A directory that’s small and trustworthy beats one that’s big and shaky.
- Build listing review into the weekly operating cadence from week one, not as a future cleanup project.
- Let AI handle the mechanical enrichment work, and keep a human in the loop for anything that’s actually a judgment call.
None of this is complicated. All of it is easy to skip when the website itself feels like the finish line. It isn’t. The listings are the product. The website is just how people find them.
That distinction matters even more once you start thinking about how the site itself gets built, which is what the next post is about: how I actually build these directories with vibe coding, without relying on an off-the-shelf directory plugin, and where that approach genuinely saves time versus where it doesn’t.
