How I Added Cross-Engine Rank Data to My Software Index with SearchApi

I run a Software Index on this site, a live ranking of SEO and AI-visibility tools by actual search demand. Until this week it answered one question: how many people search for a tool's name. It didn't answer a second, related question: when someone does search, does the engine they're using actually find the tool? That turned out not to be the same question at all, and the gap between the two is what this post is about.

What the Index Does, and Why One Engine Isn't Enough

The Software Index ranks SEO suites, SEO autopilot tools, AI content-SEO tools, and AI search-visibility (GEO) tools by a Demand Score built from DataForSEO search-volume data: how many people search a tool's name, plus long-tail phrases like "pricing" and "alternatives" that only make sense if the tool is what's being searched for. That score answers "is anyone looking for this," which is a demand question.

It never answered a visibility question: when someone searches a tool's name, does the engine actually show them the tool's own site? Those sound like they should always agree, and for a name like Semrush or Ahrefs they do. They stop agreeing for a name that's also a dictionary word or someone else's product. Profound, Conductor, Kit, Omnia, Scrunch: all real SEO/GEO tools, all names shared with something unrelated.

The Demand Score already discounts these by comparing their long-tail search share against their category's peers, exactly so a contaminated raw number doesn't get read as real demand. But that correction says nothing about what a reader actually sees when they type the name into a search box, and that's a different failure mode: a tool can have completely legitimate demand and still lose its own brand search to a dictionary definition on one engine while ranking #1 on another.

Cross-engine data is the only way to see that, because the four major engines don't agree on how to disambiguate a name. Google, Bing, DuckDuckGo, and Yandex rank different signals differently (link graphs, local indexes, how aggressively they lean on an existing knowledge base entry for a common word), so the same query can resolve to the product on one and to a dictionary entry on another. For a GEO tool specifically, that's not a trivia point: a tool whose own business is making AI engines find and cite it correctly being invisible on one of the four engines its own buyers might be using is the whole pitch, inverted.

How It's Built on SearchApi

The build is intentionally small: one query per tool (just the bare name, no extra qualifiers), run against four engines, looking for one thing per engine, where the tool's own domain first shows up in the top 10 organic results.

I used SearchApi for this instead of DataForSEO (which runs the demand side of the index) because SearchApi exposes Bing, DuckDuckGo, and Yandex as first-class engines through the exact same request shape as Google, just a different engine parameter. That's the whole reason this build exists: hitting four engines from one API meant writing one script instead of stitching together four separate scraping setups with four different response formats.

The fetch script (scripts/software-index-2-crossengine-fetch.mjs in the site's repo) does three things per tool:

• Pull the tool's official website URL from my own Sanity data and normalize it to a root domain (strip protocol, www, path).
• Query each engine for the bare tool name, 10 results each.
• Walk the organic results for a domain match, and record the position (1-10) or null if the tool's own site never shows up in the top 10 at all.

A single engine call looks like this:

javascriptconst url = `https://www.searchapi.io/api/v1/search?engine=${engine}&q=${encodeURIComponent(toolName)}&api_key=${SEARCHAPI_API_KEY}&num=10`;
const res = await fetch(url);
const { organic_results } = await res.json();
const hit = organic_results.find(r => rootDomain(r.link) === targetDomain);
const position = hit?.position ?? null; // null = not in the top 10 at all

engine is just "google", "bing", "duckduckgo", or "yandex": same endpoint, same response shape, one parameter swapped. That consistency is what made running this across 4 engines x 73 tracked tools (around 290 requests) a same-afternoon build instead of a multi-day one.

The result lands on each tool's software.crossEngineRank field in Sanity, separate from the demand data on purpose so the two fetch scripts can never clobber each other's output on a refresh. On the Software Index itself, every tool row now shows a small "G #n" badge (its Google position), and clicking it expands the other three engines inline, Google first because it's still the engine most readers actually use, the other three one click away for whoever wants the full picture.

What the Data Shows

73 tools across the index's four categories, one query per tool per engine, bare name only, top 10 results. 42 of the 73 (58%) rank #1 on all four engines at once: Semrush, Ahrefs, Moz, names with no real competition for their own string. Those aren't the interesting part. The other 31 are, and the pattern in them isn't what I expected.

I expected Google, the engine with by far the deepest index and the most SEO competition riding on it, to be the most reliable at resolving an ambiguous or generic name to the right site. It was the least reliable of the four, by a wide margin. Google failed to surface a tool's own site anywhere in its own top 10 for 19 of 73 tools (26%). Bing missed 4 (5%). DuckDuckGo and Yandex each missed 3 (4%).

That's not Google failing to know these sites exist. 18 of those 19 tools rank #1 on at least one of the other three engines, Conductor, Frase, Keysearch, Moz, NeuronWriter, Rankaria, Seobility, and Temso AI among them, all established, unambiguous SEO tools that simply lost their own brand query to something else on Google specifically. For a bare-name search with no other context, Google is choosing to rank a dictionary definition, a stock ticker, or an unrelated brand over the actual tool more often than the other three engines make that same call.

Only one tool, Cited (cited.so), is missing from the top 10 on all four engines. That one checks out on its face: "cited" is about as generic an English word as a product name gets, and nothing in these four engines' indexes currently treats it as a brand for an unqualified query. A few of the other Google-missing names (Cited, Conductor, Frase, Aiso) are ones my own Demand Score side already flags separately as nameCollisionSuspected, from search-volume ratios, not SERP position, an unrelated signal landing on some of the same names.

Bing and DuckDuckGo's miss lists nearly match: DuckDuckGo missed exactly 3 (Cited, LaunchMind, Omnia), and Bing missed those same 3 plus one more (Aiso). DuckDuckGo has long leaned on Bing's index for part of its organic results, and this is the clearest evidence of that I've seen in my own data, two independently queried engines agreeing on all but one name.

The single clearest individual case is Aiso (getaiso.com): absent from both Google's and Bing's top 10 entirely, #4 on DuckDuckGo, and #1 on Yandex. Four engines asked the identical two-syllable question, four different answers, ranging from "doesn't exist" to "the obvious first result."

What This Doesn't Claim

This isn't a ranking signal and I'm not treating it as one anywhere on the index: a tool missing its own brand search on DuckDuckGo says something about DuckDuckGo's index, or about how contested that name is, not about the tool's quality. It's also a single-query, top-10, position-only snapshot: no secondary metrics (snippet quality, knowledge panel presence, ads above the fold), and no history yet, this is a point-in-time fetch, re-run manually, not a tracked trend the way the Demand Score's 12-month history is.

If this turns out to be worth watching over time I'll turn it into one; for now it's exactly what it looks like, one afternoon's cross-engine snapshot.

The full, live data is on the Software Index, per tool, with the engine breakdown behind the badge. If you want to reproduce this yourself, the fetch script and query shape above are the whole build, swap in your own tool list and SearchApi key and it runs as-is.