TL;DR: We rebuilt our business enrichment pipeline from 20+ API calls down to 2. When testing web search providers, we discovered Gemini uses Google’s own search index—which means everything it finds, Google already knows. Zero incremental SEO value. OpenAI pulls from Yelp, Tripadvisor, OpenTable, and other non-Google sources, giving us unique content signals. OpenAI won 14 out of 15 head-to-head tests.

The Old Pipeline Was a Mess

Our original enrichment pipeline made 20+ API calls per business:

Google Places → Business details
Google CSE → Web mentions (5-10 queries)
AI Search → Industry analysis
Web Scraping → Competitor data
LLM Synthesis → Combine everything
LLM Formatting → Structure output

It worked, but it was slow (~3 minutes), expensive, and fragile. One flaky API call could cascade into bad data downstream. We needed to consolidate.

The Rebuild: 2 Calls, 90% Fewer API Requests

The new pipeline is two calls:

Call 1: Web Search — OpenAI with json_schema response format and up to 15 web search operations. One prompt asks for everything: contact info, services, reviews, competitive intel, SEO opportunities.

Call 2: Synthesis — OpenAI structured generation. Takes raw search results and produces a clean, normalized business profile with designer synopsis, mission statement, USPs, and gap-filled data.

Total execution time: ~60-90 seconds. Down from ~3 minutes.

Why Not Gemini?

Gemini was the obvious first choice. It’s Google’s model, and Google has the best search index in the world. We tested it. We were wrong.

Problem 1: Google’s Index = Zero SEO Value

This is the counterintuitive insight that changed our decision.

When Gemini searches the web, it uses Google’s own search index. Everything it finds—every fact, every review, every keyword—is data that Google already has in its index.

If we build a website using content sourced from Google’s index, we’re essentially creating a derivative of information Google already knows. There’s no new signal. No unique content. No reason for Google to rank our page higher than the original sources.

OpenAI’s web search pulls from a different index. It finds data on Yelp, Tripadvisor, OpenTable, LinkedIn, industry-specific platforms, and local directories that Google’s crawler may have indexed but doesn’t surface the same way. When we synthesize this into website content, we’re creating something with genuinely different source signals.

For SEO, the best content comes from sources Google doesn’t already surface prominently.

Problem 2: Long-Tail Keyword Quality

We compared the keyword opportunities each provider suggested:

Provider	Keywords for a Brooklyn pizzeria
Gemini	“pizza brooklyn”, “best pizza near me”, “new york pizza”
OpenAI	“late night pizza delivery prospect heights”, “coal oven pizza brooklyn heights”, “family pizza restaurant park slope birthday party”

Gemini returns generic head terms. OpenAI finds transactional long-tail keywords from review platforms and local directories. The long-tail keywords are what small businesses actually rank for.

Problem 3: Non-English Businesses

We tested with Turkish, Spanish, and other non-English businesses. Gemini returned zero grounding sources for a Turkish restaurant in New Jersey. OpenAI found Yelp reviews, TripAdvisor listings, and local directory entries.

Gemini’s grounding API appears to struggle with businesses that primarily appear in non-English contexts or on platforms outside Google’s core vertical search features.

Problem 4: JSON Schema + Web Search Don’t Mix on Gemini

OpenAI supports json_schema response format alongside web search tools. One call, structured output, grounded in web data. Clean.

Gemini’s responseMimeType: 'application/json' cannot be combined with its search grounding tools. You have to:

1. Call Gemini with search grounding (get markdown response)
2. Strip markdown fences
3. Parse JSON (often malformed)
4. Run a second LLM call to clean/restructure the data

That’s two calls with error-prone parsing, versus one clean call on OpenAI.

What About DeepSeek and Anthropic?

• DeepSeek: No web search API at all. Cheapest for text generation, but can’t discover business data.
• Anthropic: Can’t combine web search with structured output in a single call. Similar to the Gemini problem.

The Evaluation

We tested on 15 real businesses from our production data: restaurants, law firms, plumbers, salons, gyms, and more.

Scoring dimensions (0-100 each):

Dimension	What We Measured
Contact Completeness	Phone, email, address, hours (25 pts each)
Service Coverage	Number of real services discovered
SEO Value	Keywords + content gaps + directory listings
Trust Data	Ratings, review counts, platforms, praise themes
Competitive Intel	Competitors found, USPs, market positioning
Content Richness	Designer synopsis, mission statement, company history, reviews

Results: 14/15 Wins for the New Pipeline

The 2-call OpenAI pipeline beat the old 20+ call pipeline on 14 of 15 businesses. The one loss was a sparse-data case where the old pipeline’s Google Places call found a phone number that OpenAI’s web search missed.

Average scores improved across every dimension. Contact completeness, service coverage, and content richness showed the largest gains.

Architecture Details

Call 1: Web Search

const result = await performAIWebSearch({
  prompt: buildEnrichmentSearchPrompt(business),
  responseFormat: 'json_schema',
  schema: enrichmentSearchSchema,
  maxUses: 15,
  timeoutMs: 120_000,
  providerOverride: 'openai',
});

The prompt asks for everything in a single structured schema: contact info, services, reviews, competitors, SEO opportunities, trust signals. OpenAI’s search agent decides which queries to run and how many times to search.

Call 2: Synthesis

const profile = await generateStructuredData<EnrichedProfile>({
  prompt: buildSynthesisPrompt(searchResults, candidateData),
  schema: enrichedProfileSchema,
  provider: 'openai',
});

The synthesis step does three things:

1. Cleans raw search data (normalizes phone formats, deduplicates services)
2. Fills gaps with inferred data (generates mission statement, designer synopsis from available context)
3. Applies ground truth — candidate phone/address from Google Places always override AI-discovered values

That last point is critical. When a user selects their business from Google Places during onboarding, that phone number and address are authoritative. The AI might find an outdated number from a 2019 Yelp listing. Ground truth wins.

Feature Flags: Safe Rollout

We didn’t flip a switch. We built a feature flag system:

// Resolution hierarchy: DynamoDB admin override → app-config.json → hardcoded false
export async function isConsolidatedEnrichmentEnabled(): Promise<boolean> {
  const cached = getCachedFlag('enableConsolidatedEnrichment');
  if (cached !== undefined) return cached;

  const override = await getFeatureFlagOverrides();
  if (override?.enableConsolidatedEnrichment !== undefined) {
    return cacheAndReturn(override.enableConsolidatedEnrichment);
  }

  return cacheAndReturn(appConfig.featureFlags.enableConsolidatedEnrichment);
}

60-second in-memory cache, DynamoDB-backed overrides, admin dashboard toggle. We can roll back to the old pipeline in seconds without a deploy.

What We’d Do Differently

1. Start with the 2-call architecture. We built the 20-call pipeline because we assumed more data sources = better data. Wrong. One smart web search agent with a good prompt outperforms a dozen narrow queries.

2. Test non-English businesses earlier. The Gemini failure on Turkish businesses would have been a production incident if we hadn’t caught it in evaluation.

3. Always apply ground truth last. Our first version merged AI data and candidate data simultaneously. Now we synthesize first, then override with ground truth. The order matters.

Try It

Every website built on WebZum uses this enrichment pipeline. Describe your business in one sentence. Our AI searches the web, discovers everything it can about your business, and builds a site with content that Google hasn’t seen assembled this way before.