Tools Are Easy. Outcomes Are Hard. How We Build an SEO Stack That Moves Numbers

We build software in the SEO and lead-gen space, so we spend a lot of time looking at how people try to grow a website. And the pattern is almost always the same. Somebody buys Ahrefs, installs a WordPress plugin, opens fourteen browser tabs, exports three spreadsheets, and then wonders why the needle isn't moving.

The tools are fine. The tools are great, honestly. That's the problem. The tools are so good and so easy to acquire that people mistake owning them for having a system. You end up with copy-paste, manual posting, missed follow-ups, and a graveyard of broken workflows that nobody wired together. Tabs are not a strategy.

If you write code for a living, you already know this feeling. Picking a library is easy. Shipping an outcome with it is hard. SEO is the same, and looking at it like an engineer instead of a marketer is the unlock.

The trap: a shelf of tools is not a pipeline

Some numbers to set the scene, because they're genuinely wild.

Scott Brinker's martech landscape counted 15,384 tools in 2025, up about 9% year over year and roughly 100x the 150 tools that existed in 2011. So the category isn't just big, it's compounding.

And we barely use what we buy. Gartner's marketing survey found teams using only about 33% of their martech stack's capabilities in 2023, recovering to roughly 49% by 2025. Sit with it either way: half of the software you pay for never gets touched.

We see the far end of this pattern constantly. When we scanned 292 small-business sites, almost all failed a basic mobile performance check. Not for lack of tools. For lack of a system connecting them.

None of that is a tooling shortage. Nobody's problem is "I need a fifteen-thousand-and-first tool." The problem is that the tools don't talk to each other, the workflow between them is manual, and there's no pipeline connecting "I published a thing" to "a customer paid me."

So instead of shopping, build the pipeline. Here's the stack we actually reach for, bottom to top, and what each layer is really doing.

Layer 1: Keyword and backlink research (decide what to build for)

Skipping research is like writing a feature before reading the ticket. The job isn't "find high-volume keywords." It's the intersection of what people search, what you can credibly rank for, and what actually makes you money. A 40,000-searches-a-month term you have no authority to win, and that converts nothing, is worse than a boring 90-a-month term a ready-to-buy customer types in.

Backlink research is the reconnaissance half: who links to the sites already winning your queries, and whether there's a realistic path to earning similar links. You're mapping the competitive graph before you commit engineering effort.

Output of this layer: a short, ranked list of pages you're going to build or fix, each tied to a real query and a real conversion. That list is your backlog.

Layer 2: Search performance and indexing data (your production telemetry)

If you ship code without logs and metrics, you're flying blind. Same with a website. Google Search Console is the closest thing you get to production telemetry straight from the search engine, and it's free.

Two reports do most of the work:

• Search Performance: Clicks, Impressions, CTR, and average Position, sliceable by query, page, country, and device. Your "what am I actually ranking for, and where" dashboard.
• Page Indexing (the old Coverage report): which URLs are indexed, and for the ones that aren't, why. Reasons like "Crawled - currently not indexed" and "Excluded by noindex tag" are the error log of your site's relationship with Google.

Two limits will bite you if you build on top of it. Performance data is a rolling 16-month window, so export it yourself if you care about year-over-year. And the UI caps exports at 1,000 rows, which is nothing for a real site. Get past the cap with the Search Analytics API (up to 50,000 rows/day per property per search type) or the Bulk Data Export to BigQuery, which isn't row-limited. If you can write a for loop, you can pull your own data at real scale instead of squinting at the dashboard.

Don't eyeball GSC once a month. Pipe it somewhere you can query it.

Layer 3: Technical SEO audits (lint your site)

A technical audit is a linter for your site's crawlability. It isn't one official Google checklist, it's an industry-consensus set of categories, but the categories are stable, and they're the same ones our own DeepAudit AI grades:

• Indexability and directives: robots.txt, meta robots, canonical tags, HTTP status codes
• XML sitemaps: present, valid, submitted, and actually fresh
• Structured data: valid JSON-LD, eligible for rich results
• Mobile and responsive: you're being indexed mobile-first whether you like it or not
• HTTPS and security: TLS, no mixed content
• Site speed and Core Web Vitals: covered below, it's big enough for its own layer
• Internal linking and architecture: crawl depth, orphan pages, sane anchor text
• Rendering: does the rendered page match what you think you shipped

One honest caveat so you don't over-index on the wrong thing: HTTPS is a (minor) ranking signal, but specific security headers like CSP and HSTS are security best practice, not ranking factors. Do them because they're correct, not because you think they'll bump you up a spot.

Layer 4: Deep site crawls (understand crawl to render to index)

Here's the part most developers get wrong, and it matters more every year because we ship more JavaScript.

Google's pipeline is crawl, then render, then index. Every page that returns a 200 gets queued for rendering. Google runs a headless Chromium, executes your JavaScript, and indexes the rendered HTML, not just the raw source that came off the server.

That rendering step sits in a queue. Google's own docs say a page "may stay on this queue for a few seconds, but it can take longer." This is the reality behind the old "two-wave indexing" phrase people used to throw around. Google doesn't frame it as two fixed waves anymore, but the deferred-rendering queue is real and documented.

Two practical consequences:

1. Raw HTML and rendered DOM can differ, and the difference is what gets indexed. If your content only exists after a client-side fetch, Google has to render to see it, and rendering is deferred. Server-render or statically generate the content that matters.
2. Do not put `noindex` in the raw HTML of a page you want indexed and plan to "fix with JavaScript later." If Google sees noindex in the initial response, it can skip rendering entirely and never run your JS. You can't un-noindex a page client-side. We've watched this silently nuke real pages.

A deep crawl (Screaming Frog, Sitebulb, or your own script) is how you catch orphan pages, redirect chains, canonical conflicts, and raw-versus-rendered gaps before Google does.

Layer 5: Core Web Vitals (performance is a feature)

Core Web Vitals is where "SEO" and "you are a software engineer" fully overlap. There are three, all measured at the 75th percentile of real user page loads:

Note the middle one. INP replaced FID (First Input Delay) as a Core Web Vital on March 12, 2024. FID only measured the delay of the first interaction. INP measures the latency of all interactions on the page, which is a much harder and more honest bar. If your mental model still says "FID," update it.

Why bother past the ranking nudge? Because speed is a conversion feature independent of Google. Google and Deloitte's "Milliseconds Make Millions" study (2020, 30M+ sessions) found that a 0.1-second improvement in mobile load time lifted retail conversions by 8.4% and average order value by 9.2%. You'd chase an 8% conversion lift in a sprint. This is that, hiding in your bundle size.

You can measure it without guessing:

# Field data from the Chrome UX Report via PageSpeed Insights API
curl "https://www.googleapis.com/pagespeedonline/v5/runPagespeed?url=https://example.com&category=performance&strategy=mobile"

Lab tools (Lighthouse) tell you what could be slow. Field data (CrUX, the loadingExperience block in that response) tells you what real users actually feel. Optimize against the field data.

Layer 6: Content optimization (make the page legible to machines)

Once the page is fast and crawlable, make it legible, to both readers and parsers. On the machine side, that means structured data.

JSON-LD is Google's recommended format for structured data: a script block that describes the entities on your page using schema.org vocabulary. It's decoupled from your markup, so it's easy to maintain and hard to accidentally break with a CSS change.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "LocalBusiness",
  "name": "Example Co",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "123 Main St",
    "addressLocality": "Denver",
    "addressRegion": "CO",
    "postalCode": "80202"
  },
  "telephone": "+1-555-0100",
  "openingHoursSpecification": [{
    "@type": "OpeningHoursSpecification",
    "dayOfWeek": ["Monday","Tuesday","Wednesday","Thursday","Friday"],
    "opens": "09:00",
    "closes": "17:00"
  }]
}
</script>

Match the schema to the content. Use a specific LocalBusiness subtype (Restaurant, HealthClub, and so on) for a physical business, Organization when there's no storefront, and Article / BlogPosting for content like this post. Valid structured data makes you eligible for rich results (review stars, FAQs, breadcrumbs, local packs). It's widely believed to help AI answer engines cite you too, and that's plausible, but we'll be straight with you: Google doesn't document it as a guaranteed mechanism, and structured data never guarantees a rich result even when it's valid. Do it because it's cheap and correct, not because it's magic.

And it isn't only Googlebot reading this anymore. AI answer engines and LLM-backed search pull from the same clean, server-rendered content and structured markup you'd build for a rich result. The work didn't change; the audience for it did. A page that's easy for a crawler to parse is easy for a model to quote. That's a reason to hold the line on the fundamentals, not a new workstream to bolt on.

Layer 7: Lead operations (a contact form is a production endpoint)

This is the layer people bolt on last and it's the one that actually touches revenue. If you drive traffic and capture leads but nobody responds, you've built a system that carefully collects dropped requests.

The numbers on this are brutal and old enough to be settled. From the Harvard Business Review study "The Short Life of Online Sales Leads" (2011, audit of 2,241 US companies):

• Firms that made contact within an hour were nearly 7x more likely to qualify a lead than those who waited just one more hour, and more than 60x more likely than those who waited a full day.
• The average first-response time across those companies was 42 hours.
• 23% never responded at all.

Earlier MIT / InsideSales research (2007, vendor-commissioned, so grain of salt) put even sharper numbers on the first few minutes, with contact odds dropping up to 100x between a 5-minute and a 30-minute response. The exact figure is arguable; the direction isn't.

Think of an inbound lead as an HTTP request with an aggressive client-side timeout. Respond in milliseconds (well, minutes) or the connection drops. As an engineer this is the most tractable layer in the whole stack: it's automation, routing, and instant acknowledgement. You already know how to make a system respond fast. Point that skill here. It's the exact problem our Axion Deep Labs product Site2CRM automates: capture the lead, qualify it, and route it to a human the second it lands.

Layer 8: Content distribution (shipping isn't publishing)

Writing the post is git commit. Hitting publish just merges it to main. It isn't deploy, and it definitely isn't "users are running it in production."

The maxim we keep coming back to, popularized by Derek Halpern, is to spend 20% of your time creating content and 80% distributing it. It's a rule of thumb from one practitioner, not a study, and plenty of people argue it's closer to 50/50. The point survives the quibbling: most people pour everything into creation and nothing into distribution, then blame the content.

Distribution is the deploy step, so systematize it: syndicate the piece, link it from relevant answers, put it in front of people who'd actually use it. And rewrite it per destination, because LinkedIn isn't X and a dev community isn't Facebook. That per-platform rewrite is the exact job our Axion Deep Labs product Made4Founders was built to do. (One gotcha for anyone cross-posting: set rel="canonical" on the syndicated copy back to the original on your own domain, so you get the ranking credit instead of splitting it between two URLs.)

Layer 9: Measure what converts (close the loop)

Every layer above is theater if you can't answer one question: which of this produced revenue?

Rankings are a proxy. Traffic is a proxy. Even leads are a proxy. This is the feedback loop, and a pipeline without one isn't a pipeline, it's a conveyor belt pointed at a wall. Trace it end to end, from query, to landing page, to lead, to booked revenue, so you know which keyword and which page paid for itself. Connect that loop and the whole stack stops being a pile of activities and becomes a system you can profile and tune like any other.

It's also the layer that kills tool sprawl on its own. Once you can see what converts, the 33% of your stack that touches nothing measurable becomes obvious, and easy to cut.

The point

Tools are easy. You can assemble every tool named in this article in an afternoon and a credit card. Outcomes are hard because outcomes come from the system, the wiring between the layers, the automation, and the feedback loop from revenue back to your backlog.

So stop shopping for the missing tool. You don't have a tool problem. Build the pipeline instead. Drawn out, the whole thing is one loop:

   Research (Ahrefs)
        |
        v
   Backlog  <-----------------------------+
   (ranked pages, each tied to a query)    |
        |                                  |
        v                                  |
   Build & write the page                  |
        |                                  |
        v                                  |
   Technical audit + deep crawl            |
   (DeepAudit AI, Screaming Frog)          |
        |                                  |
        v                                  |
   Core Web Vitals pass                    |
   (PageSpeed Insights / CrUX)             |
        |                                  |
        v                                  |
   Publish                                 |
        |                                  |
        v                                  |
   Distribute (Made4Founders)              |
        |                                  |
        v                                  |
   Measure what converts (GA4)             |
        |                                  |
        v                                  |
   Lead ops, fast response (Site2CRM)      |
        |                                  |
        v                                  |
   Revenue --------------------------------+
   (which query and page paid off feeds the next backlog)

Every arrow is a place the work flows or leaks. The tools just sit on the boxes; the value is in the arrows, and it only compounds once that bottom one, revenue back to backlog, is connected.

That's the stack. The tools are just the parts. The system is the job.

Want to see where your own pipeline leaks first? Start at the audit layer. Run the free audit on your site. It renders your pages the way Google actually does, it's free, and there's no signup, so the report's yours to keep. If you'd rather read it together, book a free 15-minute teardown and we'll walk through what it found, no pitch.