Search engineering log

We publish the prediction before the result

A running record of the search work on gematria.today, a property we build and run ourselves.

Every entry states what we found, what we changed, and what we expect to happen, written before the outcome is knowable, and marked confirmed or wrong once it is.

Property
gematria.today
Log opened
8 August 2026
Entries
1
Predictions settled
0 of 5

Why a log and not a case study. Case studies get written after the numbers land, when it is already known which ones flatter the work. This is kept the other way round: the prediction goes up first, the result gets appended to it later, and entries that turn out wrong stay on the page with the reason. A studio that only shows you its wins is showing you an edited set.

The ledger · every change, every call, most recent first

Shipped Entry What we said would happen Outcome
2026‑08‑08 001: The self-inflicted indexing loop Impressions fall sharply; CTR rises; the three on-topic queries move off page two. Falsified if the dictionary terms are still drawing impressions in six weeks. Measuring
One row per shipped change. The outcome column starts as measuring and is only ever moved to confirmed or wrong, never quietly deleted.

The site was commissioning its own worst pages

Gematria.Today was earning impressions for archaic dictionary words (dull-pated, filamentule, gauping) and no clicks at all. The cause was not a crawler finding pages it shouldn’t. It was a loop in the site’s own code that manufactured the evidence of demand those pages needed to get indexed, once a day, every day.

The symptom

What the numbers said

Three months of Search Console data for a site a few months old. Low volume, which is normal at this stage. One number is not normal, and it is the one that matters.

Impressions 512 3 months to 6 Aug 2026
Clicks 10 All from the long tail
CTR 2.0% Against ~15% at position 1
Avg. position 15.1 Page two of results

Average position 15.1 puts the site on the second page, where click-through is negligible whatever the snippet says. That rules out the usual first move: title and meta-description rewriting is worthless here, because almost nobody is seeing the snippets. Rank is the binding constraint.

The genuinely diagnostic figure is buried in the query breakdown. Every one of the top eight queries by impressions returned zero clicks. All ten clicks came from queries below them.

Sorted by impressions, the top of the list splits cleanly in two. Five terms are archaic English words someone was looking up in a dictionary. Three are people asking how gematria works, which is precisely what the site is for.

Top queries by impressions · 3 months to 6 Aug 2026

Top eight search queries by impressions, with clicks and classification
Query Impressions Impr. Clicks What the searcher wanted
dull-pated 160 A definition
gematria blog 90 Our content
filamentule 70 A definition
gauping 60 A definition
well-affectedness 60 A definition
chronogrammatic 60 A definition
how to use gematria 60 Instructions
gematria calculator how to use 50 Instructions
Bar length encodes impressions; color and the label beside it encode what the searcher was after. The five dictionary terms account for 41 impressions and nothing else: a person searching filamentule wants a meaning and is offered a number. The three on-topic queries are 20 impressions of real, unserved demand.

Two findings, not one: something is publishing dictionary pages we never wrote, and nothing is answering the question our actual audience is asking.

The finding

Where the dictionary pages came from

The site generates a page for every word in its database: /w/light gives the word’s gematria value and lists every other word sharing it. There are tens of thousands of rows, so publishing all of them would be exactly the mass of thin pages that Google’s helpful-content signals exist to catch.

A guard against that already existed in the code. Only words somebody had actually looked up were offered to search engines: in SQL, search_count > 0. Reasonable rule. It did not hold, because the site was supplying the lookups itself.

The loop, and where it was cut

Wordnik picks a word of the day The home page builds a calculator link for it Opening that URL runs the lookup on page load The word now qualifies for indexing The page is crawled, indexed, and ignored an obscure one, by editorial design /calculator.html?query=dull-pated INSERT INTO words … search_count = 1 the whole gate was: search_count > 0 16 impressions, 0 clicks on every crawl of the home page no human ever typed the word one lookup was enough served for dictionary intent CUT intent=view CUT 3 searches + 5 siblings repeats daily: a new word every 24 h
The dashed return path is what turned a one-off into a supply line: a fresh archaic word entered the index every day without anyone touching the site. The two solid marks are where the fix severs it: the page-load lookup no longer writes to the database, and the indexing gate now asks for more than a single write.

Two further callers fed the same loop. A single search fanned out into a database write for every related word the dictionary API returned, registering a dozen searches the visitor never made. And the site’s own definition pages turned every long word in a definition into another one of those calculator links, so crawling one definition seeded a page for each word inside it.

The corroboration

The date stamp that confirmed it

A mechanism you can describe is a hypothesis. What made it a finding was the timing, and the timing came from version control rather than from the analytics.

The generated word pages and their sitemap were committed on 27 July. Impressions had been flat at a handful a day for two and a half months. They stepped up two to four days later, the ordinary lag between submitting a sitemap and Google working through it. This is not a site that started growing. It is a site that started being crawled somewhere new.

Daily impressions · 14 May to 6 Aug 2026

80 60 40 20 0 27 Jul: word sitemap committed commit 5bb68e6 peak ≈ 70/day flat at 2-8 a day for 75 days then 25-50 14 May 1 Jun 1 Jul 6 Aug
The shaded envelope is the reported daily range in each regime, not per-day values, drawn this way because that is the resolution the figures were supplied at, and drawing a precise line would claim precision the data does not have. Between half and two thirds of the quarter’s entire impression count lands in the final ten days.

A second leak, found the same way

Reading the surrounding code turned up a route nobody had flagged. The site’s definition pages (/definition?word=filamentule) were serving fully indexable HTML: titled Definition: filamentule, canonical to themselves, carrying no robots directive at all, and with a body consisting of a third-party dictionary’s text reproduced verbatim. The home page linked a fresh one every day.

For a query like filamentule, that page is a closer match than the gematria page it was assumed to be. Some share of the leaked impressions was almost certainly this route: a page that would never have surfaced in a crawl-based audit, because from the outside it looks like a perfectly ordinary content page.

The change

What shipped

Four changes, in one reviewed pull request. The first two close the loop; the third stops the republishing; the fourth serves the demand that was going unanswered.

  • The lookup no longer counts as demand when nobody asked for it. Page-load lookups declare themselves, return the value as before, and neither create a row nor increment one. Applied to the query prefill, the name prefill, and the related-word fan-out.
  • The indexing gate now asks for demand and substance. A word page needs repeated searches and enough words sharing its value to be a genuine list rather than a lone letter sum. Both conditions are applied in one shared definition, used by the page and the sitemap alike.
  • Definition pages are out of the index. Delivered as a meta tag and an HTTP header, and deliberately without a robots.txt block: a blocked page cannot be re-read, so blocking it would have frozen every existing URL in place rather than removing it.
  • A real answer to the on-topic queries. A guide covering what the queries actually ask, including the part competitors leave out: the arithmetic reasons most gematria “matches” are inevitable rather than meaningful.

Why a threshold, and not simply hiding the pages

Blanket removal was tempting: at ten clicks a quarter there is nothing to lose. It was the wrong call, and the reason is worth stating because it is the kind of judgment the numbers alone don’t make.

Option Stops the leak Keeps what’s differentiated Cost
Hide every generated page Yes No Throws away the value pages, which aggregate data no dictionary holds and match on-topic intent
Write real content for all of them Yes Yes Not viable across tens of thousands of pages: there is no source of substance beyond a letter sum
Raise the threshold Chosen Yes Yes Some currently-indexed pages drop out; the exact count is only knowable from the live database
The distinction that decides it: a page restating a dictionary headword competes with dictionaries and loses, while a page listing every word in the database sharing one numeric value is content nothing else has. Those are different assets and the fix had to keep the second.

The call

Recorded before deployment

Written on the day the change merged, with the baseline fixed and the expected outcome stated in advance, including the part that will look like a failure.

Recorded before deployment 8 Aug 2026 · baseline: quarter to 6 Aug 2026
  • EXPECT Total impressions will fall, probably sharply. The leaked dictionary terms were a large share of the 512. Removing them is the intended effect. Any report treating an impression decline here as a regression has misread the objective.
  • EXPECT CTR will rise as impressions fall, because the denominator was inflated by queries the site was never going to satisfy. The interesting figure is clicks, not ratio.
  • TARGET The three on-topic queries move off page two. Baseline for how to use gematria, gematria calculator how to use and gematria blog: 20 impressions, 0 clicks, at an average position of 15.1 sitewide. That is the number to beat.
  • TIMING Weeks, not days. Every affected URL has to be recrawled before the directive is seen. Sitemap output is cached for six hours; recrawl is on Google’s schedule, not ours.
  • FALSIFIES If the dictionary terms are still drawing impressions in six weeks, the diagnosis was wrong: either the leak runs through a route not found here, or the pages are held in the index by something other than the mechanism described above.

One number is deliberately absent: how many generated URLs were index-eligible. It is written at runtime and readable only from the production database, so it was shipped as a reporting command rather than estimated here. Guessing it would have been the easiest sentence in this document to write.

OUTCOME · PENDING

Nothing measurable yet. The affected URLs have to be recrawled before any of this shows up, so the first honest read is due around mid-September 2026. This block gets filled in with the actual figures then, whichever way they go, and the prediction above will not be edited to match them.

The check

How it was verified

SEO changes are unusually easy to get wrong quietly. A gate that silently stops matching, a sitemap that keeps serving a stale cache, a threshold nobody can find later: all of them fail without an error. So the reasoning went into the test suite alongside the code.

Tests passing 841 24 new, none skipped
Files changed 22 One reviewed pull request
Lines added 1,066 Against 66 removed
Build checks 9 All green on merge

The tests assert things a linter cannot: that a single lookup no longer qualifies a word, that the read-only branch returns before any database write, that the sitemap and the page apply the same two conditions, that the definition pages carry the directive and stay crawlable so it can be read. Every number quoted in the new guide is recomputed by a test against the site’s own engine, so a published claim cannot drift from the arithmetic behind it.

One helper was deleted rather than kept: a convenience function that answered “is this page publishable?” from a single database row. It could only ever check half the rule (how many other words share a value is a property of the whole table) while reading like the whole of it. That gap is roughly how the original one-lookup gate survived as long as it did.


Method

How we work

A crawl-based audit would have found the thin pages in entry 001. It would have recommended removing them, and that recommendation would have been half right and quietly incomplete, because the guard against thin pages already existed in this codebase and was already failing. The pages would have come back.

The finding needed three things a scan doesn’t have: reading the request path from the home page through to the SQL write, checking the commit history against the date the impressions moved, and knowing that a robots.txt block would have cemented the problem it appeared to solve.

Search data tells you a symptom. The cause is nearly always in the code, and it is nearly always something the site is doing to itself.

The same approach applies to any content-generating site: catalogs, listings, user-generated archives, programmatic landing pages. Wherever pages are created by a rule rather than by a person, the rule is worth reading before the reports are.

This log is kept for a property we own, which is the only place we can publish predictions before results without asking a client to carry the risk of being wrong in public. Client work follows the same method and gets the same write-up privately.

There is a second log for StellarReach, the other product we build and run. Its first entry is the opposite kind of finding to this one: nothing in the code was broken there; the site was simply addressing half the audience it sells to.

Gematria.Today is built and operated by Lunar Web Studio LLC. Search figures are as reported by Google Search Console for the stated period; commit references, test counts and diff statistics come from the project repository and are reproducible from it. Entries are appended, not rewritten: where a prediction turned out wrong, the original wording stays and the outcome block says so.

Free · No obligation

Is your site doing something like this to itself?

Most sites that generate pages from a rule (catalogs, listings, location pages) have a version of entry 001 somewhere in them. If you have a site today, send us the address and we will rebuild your homepage around your own brand and words, back within one business day. If what you need is a look at why search isn’t working, tell us and we will come back with what we find instead.