sIndeX

The problem

SEO work has a large repetitive core. Someone pulls query and page data out of Search Console, checks indexing status, cross-references against analytics, sorts by whatever proxy for opportunity they trust, and writes up the same shape of report. Then they do it again next month against slightly newer data.

The analysis part is judgment. The data assembly part is not, and it was consuming most of the hours. sIndeX was built to remove the second part.

Approach

The system pulled search-performance data through Google’s APIs on a schedule, normalized it into a consistent internal shape, and ran opportunity detection over the result. The detection logic looked for the standard structural signals: queries ranking just below a meaningful position threshold, pages with impressions but weak click-through, coverage and indexing gaps, and cannibalization where several pages competed for one query.

Most of the engineering effort went somewhere less interesting than the analysis. Google’s APIs impose quotas, paginate aggressively, and sample data in ways that are not always announced. A naive client works fine on a small site and falls over on a large one. I ended up building the data layer around three assumptions: every request can fail, every result set is larger than the page you were given, and yesterday’s numbers can change after the fact. That meant retry with backoff, cursor-based pagination with resumable state, and treating the local store as a cache that reconciles rather than a source of truth.

The workflows themselves were the actual product. Each one was a reusable definition of a recurring analysis, parameterized by property, so a piece of work done once could be replayed against any site without touching code.

Outcome

sIndeX was acquired in February 2024 by Michael Paul Salinas, a U.S. Marine veteran and entrepreneur, who took it on to run within his own operation.

What I’d do differently

I built the ingestion and the analysis as one system. That was the wrong seam. The valuable, durable piece was the reliable data layer, since API quirks and quota handling took the longest to get right and changed the least. The opportunity heuristics changed constantly as I learned more about what actually mattered. Separating them cleanly from the start would have let the heuristics move fast without risking the part that had to be dependable.

I also underweighted the fact that ranking signals are a moving target. Rules tuned against one period of search behavior decay, and there is no alert for a heuristic that has quietly stopped being useful. If I built this again I would version the heuristics and keep enough historical output to detect when one starts disagreeing with reality.

The wider lesson was about scope. The temptation with an automation tool is to keep adding analyses until it becomes a general reporting product. The version that was worth something did one recurring job reliably rather than many jobs partially.