The 28-day data for /tools/pe-ratio-calculator/ showed "forward pe calculator" sitting at position 6.7. The page was improved on May 13 — new forward P/E benchmarks sourced from FactSet, a HowTo JSON-LD schema block, and an AI-citeable answer section added to help with AI Overviews. Position 6.7 on the exact sub-query the improvement had targeted. I was 200 words into a success post when I thought to split the data by improvement date.

The ranking was already there. Before the commit.

The setup

The automation has now run 41 times across the tool library — one page per night, no missed days since mid-April. This week's run covered P/E Ratio (May 13), SaaS Valuation (May 14), Book Value (May 14), Valuation Multiple (May 15), Burn Rate (May 16). The pattern is consistent: pull current benchmark data, add worked examples, add HowTo structured data, wire in internal links. 31 pages improved in the last 30 days alone.

The question I've been trying to answer for six weeks is whether any of this is measurable in GSC. This week I had what looked like a candidate.

What I expected vs. what the data showed

The 28-day page-level data looked encouraging for the P/E calculator:

When I pulled the query-level breakdown, "forward pe calculator" showed at position 6.7 — the exact sub-query the May 13 improvement had directly targeted by adding a forward P/E benchmark table and a dedicated answer block.

This looked like evidence. The automation added forward P/E content. A forward P/E query surfaced near page 1. Clean cause-and-effect.

Then I ran the narrow windows.

Finding #1: The ranking existed before the improvement

Pre-improvement window (May 6–12 — the full week before the May 13 commit):

"Forward pe calculator" was at position 4.5 the week before the improvement went live. One click. Already on page 1.

Post-improvement window (May 13–17):

"Forward pe calculator" dropped from 4.5 to 12.0 after the improvement. The 28-day aggregate had averaged them together — 4 impressions at 4.5, plus 1 at 12.0, plus one earlier impression somewhere around 10 — and produced position 6.7. Which looked like a result the change caused.

It wasn't. The sequence I had constructed from the aggregate was backwards.

This is the same trap as the loan payment calculator from Week 1: an aggregate position metric telling a plausible story that the underlying distribution immediately contradicts when you open it. There, the "average position 9.8" hid a distribution from position 2.5 to position 98. Here, the "position 6.7 after improvement" hid a timeline where the best result predated the work.

Finding #2: The improvement did something — just different

The post-improvement window does show real effects.

"Pe ratio calculator" — the head term — moved from position 60.0 to 50.3. Ten positions. Small sample (3 impressions each), but a directional movement on the competitive query. Three queries appeared that weren't present in the pre-improvement week: "ratio calculator" at 9.0, "price earning ratio calculator" at 11.0, "debt to earnings ratio calculator" at 21.0.

"Ratio calculator" at position 9.0 is notable — it's a broad, generic query, and the page apparently matched it more strongly after the sector benchmark table and structured data were added. One impression. Too small to act on. But it wasn't there the week before, and a broad classification query appearing at position 9 is a different outcome than a specific long-tail query holding a position it already had.

The improvement created new query surface on generic and related terms. It didn't create the specific "forward pe calculator" result I was about to credit it for.

Finding #3: 78% of the P/E calculator's impressions are invisible

The 28-day page-level data: 516 impressions for the P/E calculator. The query-level breakdown: 113 visible impressions across 25 queries.

403 impressions — 78% of the total — are below GSC's privacy threshold. Individual queries with 1–2 impressions each. GSC counts them in the aggregate and won't tell you what they are.

This matters for the attribution question. "Forward pe calculator" was visible because it accumulated 4 impressions in a single week. Everything below the threshold is invisible — could be sitting at position 2.0 on a query I'll never see, or at position 90. The pre/post split I ran above only reveals the above-threshold queries. The 403 impressions below could contain a dozen more latent near-page-1 results — or none.

The query breakdown for the 28-day window returned 25 visible queries. The page is matching at least 403 additional search variations that never surface. Some of those were there before any improvement. Some might be new. I can't tell.

Finding #4: The og:title tag is confirmed still live

While verifying the P/E calculator's HTML state after the improvement, I ran the standard og:title count:

$ curl -sSL -A "Googlebot/2.1" "https://valuefy.app/tools/pe-ratio-calculator/" | \
  grep -cE '<meta property="og:title"'
2

Two tags. Static generic one in index.html, React Helmet one in the rendered output. Eight weeks since it was first flagged. Still there.

I won't relitigate this — Week 5 covered why it exists and what the wrong assumption was. But it's worth noting that every improvement the automation commits — including the structured data additions and benchmark updates on the P/E page — lands on a page that still ships a generic site-wide title as its first og:title signal.

What I'm going to do about it

1. Run pre/post splits before claiming attribution. From now on: whenever an improved page appears in the weekly GSC data, the pre-improvement window check runs first. The aggregate is for trend-watching; the narrow window is for attribution.

2. Check "ratio calculator" in two weeks. It appeared post-improvement at position 9.0 with 1 impression — too thin to act on, but if it appears consistently in the next cycle, it means the structured data additions are catching broader classification queries. That would be the actual story of what the automation builds.

3. Run the same analysis on three prior improvements. The April batch covered EBITDA, ROAS, CTR, CPC, DCF, Cap Rate, and a dozen others. Some of those pages are generating impressions. I want to know whether the rankings on those pages were latent before the improvements or created by them — same method, pre/post split on the commit date.

4. Fix the static og:title. Not because it's clearly blocking anything — the P/E calculator is generating clicks and position movement despite it. But eight weeks is long enough. It's one line removed from index.html.

The uncomfortable lesson

Aggregate time windows are good for tracking trends. They are bad for attribution.

When I saw "forward pe calculator" at position 6.7 in the 28-day data after a May 13 improvement that explicitly added forward P/E content, my brain completed the pattern: improvement → ranking. The temporal overlap made it feel true. The aggregate was doing nothing wrong — it was accurately reporting a 28-day average. I was the one reading sequence as causation.

Every improvement the automation makes now has to be verified with a pre/post split before I write about it. Not as a final check, but as the first step. If the ranking was already there, the post isn't about that ranking. If the ranking appeared cleanly after the commit, then we have something to say.

The good news: the improvement did real work. "Ratio calculator" at position 9.0. "Pe ratio calculator" moving from 60 to 50. New query surface that wasn't there before. That's a more modest story than "the automation hit page 1" — but it's a true one, and it'll compound if the pattern holds across 30+ pages.

I'll come back in two weeks with the pre/post analysis on the April batch. Either the rankings were latent and the automation is revealing them, or the improvements are actually creating new surface. That's a question the data can answer.

I'm running these experiments on valuefy.app and writing the findings as I go. If you're building programmatic SEO or fighting the same "the aggregate looks fine but the distribution is hiding something" problem, I'd like to compare notes — drop a comment or reach out.

I also run AImiten, where we build AI tooling for companies. This side project is where ideas get stress-tested before they touch client work.