Google Was Reading Our Ticker as a Different Coin

A freelance SEO job wrapped up this morning. Small site, tight scope: an alt-coin mining pool that had a genuinely good product, real customers, and zero organic visibility. Not “we’re on page four” invisible. Not-in-the-top-twenty invisible. For its own name-plus-pool-type keyword, the site was nowhere.

The interesting part is that the site was well-built. Fast. Responsive. Clean HTML. Two languages. Real docs pages. Structured data. The kind of site that a normal SEO audit tool would score in the mid-eighties and shrug at.

Two things were doing all the damage. Both were invisible on the page. Both took maybe forty lines of code to fix. Both are the kind of gotcha that a general-purpose SEO audit will never surface for you.

Gotcha one: Google was reading the ticker as a different coin

The pool mines a niche fork of Bitcoin — not the original chain. The fork has two names in the market: an old ticker that dates back to the fork’s launch, and a newer ticker that’s used on modern exchanges. The site’s <title> tag led with the old ticker.

That was the whole problem.

Google’s title comprehension is smarter than “match the string.” It reads the whole title as a phrase and tries to figure out what the page is about. When I ran a live SERP check for the phrase that started with the old ticker plus “mining pool,” every single result on page one was for a completely different hashing algorithm than the coin actually uses. Not a single result for the right one. Google was reading the old ticker and pattern-matching it to a much older Bitcoin fork that had briefly used the same abbreviation years ago.

So the site was ranking. It just wasn’t ranking for its own coin. It was theoretically competing with a category of pools that its miners couldn’t even connect to, because the hashing algorithms are incompatible.

The fix was almost embarrassingly small.

<title>OLD_TICKER (NEW_TICKER) Mining Pool for XYZ ASICs | Pool Name</title>

<title>NEW_TICKER (OLD_TICKER) Mining Pool for XYZ ASICs | Pool Name</title>

That’s it. Reorder the two tokens. Lead with the newer ticker — the one Google associates with the correct coin — and demote the old ticker to a parenthetical. The H1 got the same treatment: instead of leading with “Mine [old-ticker],” it now leads with “The mining pool for [chain name].” The words are still there for readers who search the old way. The lead token is now the one Google’s model has correctly categorized.

Three days after the change, the site’s homepage started appearing on the correct SERP for the first time. Not in the top spot. Not even top ten. But finally in the results at all — which is the difference between a rankings problem and a categorization problem. You cannot outrank pages you’re not on the same results page as.

Gotcha two: the publisher pointed at nothing on 24 pages

The second one was subtler and cost more thinking to catch. The site had structured data — good structured data, on paper. Every topic page carried an Article node with a headline, image, dates, an author, and a publisher.

The publisher was declared with a JSON-LD @id reference:

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "How to connect your miner",
  "publisher": { "@id": "https://poolsite.example/#organization" },
  "author":    { "@id": "https://poolsite.example/#organization" }
}

Which looks correct. And on the homepage, it was correct — the homepage carried the full Organization node with that @id, and the reference resolved perfectly inside the same document.

The problem is that on the 24 topic pages, the Organization node with that @id didn’t exist. Only the reference existed. And Google’s structured data parser does not cross-document lookups. It doesn’t say “oh, I remember seeing that node on the homepage, I’ll use that one.” It sees a reference to a node that doesn’t exist on this page and treats the field as empty.

So on 24 pages — the ones that actually needed publisher signals, because they were the how-to guides and the technical docs — the Article node had no publisher. No author. Which is exactly the kind of E-E-A-T thinness that gets crypto content deprioritized in the current model.

The fix was to add a short, inline Organization node to every topic page — headline, URL, logo — and let the @id on each page resolve inside its own document. Roughly ten lines of JSON per page. Same organization, just repeated. Schema.org is explicit that this is fine and expected; the trap is thinking you can DRY it out by referencing across pages.

The pattern under both mistakes

Both problems had the same shape. On-page audit tools looked at the site and saw a title tag and a JSON-LD block and marked them present. Google’s actual comprehension of those two things — what industry the page belongs to, what entities are being asserted — was completely different from what the code looked like on paper.

That gap is where the interesting SEO work lives now. Everything else — page speed, mobile rendering, alt text, canonical tags — is mostly a solved-problem checklist. The bots are looking at your content and asking two questions that no checklist tool answers cleanly: “what is this page actually about?” and “what entity is publishing it?”

If your title tag confuses the first question, your rankings vanish. If your structured data breaks the second question, your E-E-A-T signals evaporate. Neither shows up as an error anywhere. The audit tool tells you the field is present. Google tells you nothing at all. You just don’t rank.

The tell, in both cases, was going to the actual SERP for the actual query and asking whether the page belonged there. When the answer is “everyone on this page is in a different category than us,” the fix isn’t more content. It’s re-examining what the page is telling Google it is.

Two mistakes. Forty lines of code. A site that spent months invisible is finally on the map. The lesson I keep pulling out of jobs like this: static SEO audits catch spelling errors. Live SERP audits catch the ones that were killing you.