Spike Search

What’s on the site

The idea

I run several side project sites, and each has its own property in Google Analytics and Search Console, so five sites meant ten places to look. I wanted one screen that shows every site and says what to fix first, with a reason I can read in a sentence.

How it’s built

Spike Search asks Google for your data with read-only access, keeps a daily snapshot of each site in one folder on your computer, and compares this week with last week. Every fix is scored on impact, severity, confidence and effort, and anything that stops Google seeing a page goes to the top. Late Search Console data is shaded as not final, and estimates are labelled.

Stack Google Analytics · Search Console · Core Web Vitals · local-first storage

Skills it shows

• Search and analytics data: combining Analytics and Search Console across many sites and reading what the numbers actually mean.
• Prioritisation and product thinking: a scoring approach that ranks fixes by impact, severity, confidence and effort, with all four shown.
• Privacy by design: read-only access, local storage and no tracking, chosen from the start.
• Technical SEO: indexing, metadata and Core Web Vitals, plus notes written around real searches.

What I learned

• Numbers aren’t decisions. The value is in the ordering and the reason beside each fix.
• Show your working. Displaying all four scores builds more trust than one clever number.
• Be honest about uncertainty. Shading late data and labelling estimates stops people chasing problems that aren’t real.
• Privacy can be the product. Keeping everything on the user’s computer removed whole categories of risk.

Behind the scenes

Why I built it

I run several side project sites at once. A few are proper projects, like jdmmeikan.com and liveinbne.com, and the rest are weekend ideas I launched to see if anyone would care. Checking them all had become a chore.

The goal was simple: one screen that shows every site and says what to fix first. Google Analytics and Search Console are both accurate, but they don't talk to each other. Each site has its own property in each tool, so five sites means ten places to look.

The existing workarounds didn't fit. Checking by hand is fine for two sites and painful past that. Blended reports take slow setup for every new site, and scripts give you accurate numbers with nothing to look at.

Most dashboards also show numbers, not decisions. I wanted a ranked list of fixes, each with a plain reason, so I could spend my limited time on the change that matters most.

Who it's for. The primary audience is builders running several sites who are comfortable with a few terminal commands. The secondary audience is any site owner trying to read Analytics and Search Console together, which is who the Notes pages are written for.

What it deliberately doesn't do. It never changes your sites, because its access to Google is read only. There's no account, no hosted version, no tracking inside the app and no subscription. It only reads Google data, and it doesn't pretend to know more than that data can tell it.

The methodology

Spike Search is built on a handful of rules. I've written them up in plain language on How it decides.

1. Google's own data, read only. Every number comes from your own Analytics and Search Console accounts. The app can look, but it can never change anything.
2. Every fix is scored four ways. How much it could help, how serious the problem is, how sure the app is, and how much work it takes. All four sit next to each fix, so nothing is a black box.
3. Visibility comes first. Anything that stops Google seeing a page goes to the top, because no other fix on that page helps until Google can see it.
4. Every item has a reason. No fix appears without a plain sentence explaining why it's on the list.
5. Late data is marked, never guessed. Search Console data arrives two to three days late. Those days are shaded as not final, rather than hidden or filled in.
6. Estimates are labelled. Some numbers, like the clicks a page should get at its position, are estimates. They're marked as estimates wherever they appear.
7. Your data stays with you. Daily snapshots are kept as plain files in one folder on your computer. Deleting that folder deletes everything.
8. Sample data in public. Every screen on the website uses made up sites and numbers, so nobody's real traffic is ever on show.

Where the data comes from

Spike Search has no data of its own. It asks Google for yours, with read only access you set up, and keeps a daily snapshot of each site so it can compare this week with last week.

It doesn't yet cover Bing or any analytics tool outside Google.

The hard problems

The interesting work was in the gaps between what Google reports and what a site owner needs to know.

Two tools that never quite agree. Search Console reports in US Pacific time, while Analytics uses each property's own time zone, so daily numbers won't line up exactly. Rather than force them to match, I put both on one chart over the same dates and explain why they differ.

Data that arrives late. Search Console runs two to three days behind, so the newest days always look like a drop. I shade those days as not final, which stops false alarms without hiding anything.

Deciding what comes first. A long list of issues is just another dashboard. I score every fix on impact, severity, confidence and effort, show all four, and push anything that hides a page from Google to the top.

When Google doesn't answer. With several sites, one request will eventually fail. If that happens, the other sites still load and a note names the missing one, instead of showing an empty screen.

Showing a private tool in public. The app only ever sees your own data, so I couldn't screenshot real traffic. I built a set of made up sample sites with a clear story, like one site down 18.6% in search clicks, so the screens explain themselves.

Knowing when to change direction. The spikesearch.com domain first hosted a different idea that didn't work. I also ruled out a hosted version as too complicated for now, and chose a self hosted, pay once app that I could ship honestly.

Technical SEO and organic traffic

A tool about search visibility has to earn its own. Here's how I approach it.

Matching pages to real searches. Every page answers something people actually type. The Notes cover questions like the difference between Search Console and Analytics, or a good click through rate for a page ranking 5th.

Content clusters and internal linking. Each note ties back to the product page that solves the problem it describes. The home page, How it decides, Privacy and Notes all link to each other, so search engines and readers can follow the thread.

Technical foundations. Every page sets its own title, description, canonical URL and social preview. Fonts are served from the site itself, pages are light and fast, and the layout works on a phone.

Fast indexing. I submit new pages through Google Search Console and Bing Webmaster Tools, and ping IndexNow when content changes. Clear, direct answers also give a page a better chance of being cited by AI search tools.

Trust signals. A plain privacy page says exactly what runs where. The site names who made it, lists what the app can't do yet, and labels every screen as sample data.

Building things worth linking to. The best links come from being useful. Honest answers to common Search Console questions, and a free look at how the ranking works, are worth sharing on their own.

What's next

• A step by step setup guide. Setup is the biggest hurdle today, so a clear guide comes before anything else.
• A live demo. A clickable version with sample sites, so people can try the ranked list without connecting anything.
• A private beta, then a founding price. Waitlist members hear first, with a pay once price and no subscription.
• Sharper flagging. The checks are still in beta, and I'm refining them as I use the app on my own sites.