Technical SEO Consultant
Traffic drops. Pages disappear from Google. Indexing stops making sense. A migration goes through and performance never comes back. Every tool reports something different.
I investigate what’s actually happening, identify the root cause and give your team a clear path to fix it.
| Crawler A | 0 critical issues |
| Crawler B | 14,802 errors |
| Search Console | "Crawled – not indexed" |
| Site audit tool | Health score 94 |
| Your analytics | -38% organic |
The diagnosis
Six things I find over and over. None of them are obvious from the outside, which is why nobody has told you yet.
01
WHAT YOU SEE
Your store has 5,000 products. Search Console reports Google is crawling 500,000 URLs. Nobody knows where the other 495,000 came from.
WHAT MAY BE HAPPENING
Faceted filters, sort parameters, session IDs, internal search results and pagination combining into URL patterns that multiply without limit.
WHAT I INVESTIGATE
Which URL patterns actually deserve crawling, which don’t, and how search engines are discovering the ones that shouldn’t exist.
02
WHAT YOU SEE
The page loads fine. It’s in the sitemap. Search Console says “Crawled — currently not indexed” and offers no explanation beyond that.
WHAT MAY BE HAPPENING
Discovery depth, thin or duplicated content signals, canonical conflicts, quality thresholds, or crawl priority being spent elsewhere.
WHAT I
INVESTIGATE
How the page is discovered, what Google receives when it fetches it, and what distinguishes it from the pages that did get indexed.
03
WHAT YOU SEE
The page you want ranking never appears. A near-duplicate — a filtered view, a print version, an old URL — shows up instead.
WHAT MAY BE HAPPENING
Canonical tags contradicting internal links, sitemaps or redirects. Google treats canonicals as a hint, and when signals conflict it makes its own choice.
WHAT I
INVESTIGATE
Every signal pointing at the URL: canonical, hreflang, internal links, sitemap entries, redirects and where they disagree.
04
WHAT YOU SEE
The page looks complete in your browser. Google ranks it for almost nothing, as though half the content isn’t there.
WHAT MAY BE HAPPENING
Content injected client-side after load, blocked resources, hydration failures, or a rendered version that differs from what a visitor sees.
WHAT I
INVESTIGATE
The raw HTML against the rendered DOM, what’s present at each stage, and which elements never make it into the indexed version.
05
WHAT YOU SEE
Your highest-margin pages sit six clicks from the homepage, while low-value pages sit two clicks away and get crawled constantly.
WHAT MAY BE HAPPENING
Navigation built around how the business is organized internally rather than how demand is structured, plus internal linking that never got revisited as the site grew.
WHAT I
INVESTIGATE
Click depth against commercial value, where internal authority is concentrated, and which pages are effectively orphaned.
06
WHAT YOU SEE
The new site launched. Redirects were checked. Weeks later, traffic is down and never fully recovers.
WHAT MAY BE HAPPENING
Redirect chains, lost internal links, changed templates, altered content depth, dropped structured data, or a robots directive that shipped with the build.
WHAT I
INVESTIGATE
A full before-and-after comparison: URLs, rankings, templates, internal links and markup to find what actually changed beyond the addresses.
07
WHAT YOU SEE
One audit says the site is healthy. Another lists fourteen thousand errors. Search Console tells a third story. Every report is technically accurate.
WHAT MAY BE HAPPENING
Different crawlers use different user agents, render differently, respect directives differently and sample differently. They aren’t looking at the same site.
WHAT I
INVESTIGATE
Server logs – what Googlebot genuinely requested and received. Not a simulation of crawling, but the record of it.
Why audits miss this
What a tool produces
Modern SEO tools are genuinely excellent at what they do. They will find the broken links, the missing tags, the redirect chains and the slow templates and they’ll find them faster than any person could.
What they can’t do is tell you which of those 14,802 findings is causing your problem or whether any of them is. That judgment isn’t something a crawler is built to make.
Screaming Frog
Search Console
Server logs
Crawl data
Rendering tests
Redirects
Canonicals
Sitemaps
robots.txt
What I do with it
The hard part of technical SEO isn’t collecting evidence — it’s reasoning from it. Two sites can show identical crawl reports and have completely different underlying problems.
So I read the same data your team has, plus the data most audits skip, and work backwards from the symptom until the cause is confirmed rather than assumed.
You don’t need another SEO audit. You need someone who can figure out what is actually broken.
The investigation
Five stages, in order. Nothing gets recommended before it’s been verified.
What changed?
Timeline of traffic, indexing, rankings and deployments, lined up against each other.
Where is it happening?
Which templates, sections, URL patterns or page types are affected and which aren't.
Can we prove it?
Reproduce the behaviour against logs, live fetches and rendering tests before calling it the cause.
What's the root-level fix?
Developer-ready specifications your team can ship, in priority order, with the reasoning attached.
Did it actually work?
Crawling, indexing and organic performance tracked afterwards to confirm the fix moved what it should.
When companies bring me in
Most of my work comes from teams that are capable. The internal SEO lead knows what they’re doing, the developers are competent and the agency’s audit was thorough. The problem is that a technical diagnosis needs someone who can sit between all three and that person usually doesn’t exist on the org chart.
What I solve
Grouped by what’s actually going wrong — not by what’s easiest to put on an invoice.
Real client result
technical health score
keywords ranked in 5 months
Real client result
Shea Terra Organics had been selling online since 2004. The brand was real, the products were established, and organic performance was well below what a site of that age should have been producing.
The diagnosis
Technical issues, weak keyword targeting and limited authority signals were compounding. None of them were visible as a single obvious failure — which is exactly why the site had been underperforming quietly for so long.
The intervention
A white-hat, data-driven programme covering technical SEO, on-page optimization and authority growth — executed in that order, so later work had something solid to build on.
Why it worked
Technical health moved from 69% to 92%, keyword coverage nearly tripled, and organic traffic roughly doubled inside five months. The content and authority work was only able to compound because the foundation could finally carry it.
Engagement: November 2022 – April 2023 · Duration: ~5 months
What you actually get
What is actually wrong, stated plainly, with the evidence that confirms it.
Not the list of symptoms — the thing underneath them that's producing the symptoms.
Ordered by impact and effort, so your team knows what to ship first and why.
Written so an engineer can pick up a ticket and implement it without translation.
Available while the work is being built, not just at handover.
Confirmation that crawling, indexing and performance actually responded to the fix.
Working directly with your internal team and developers as questions come up.
The gap between a technical recommendation and a shipped fix is where most SEO engagements quietly fail. A document gets delivered, it enters a backlog, priorities shift, and six months later nothing has changed.
So the diagnosis is the beginning of the engagement, not the end of it. I stay involved while the work is being implemented, answer your developers’ questions directly and verify afterwards that the fix did what it was supposed to.
If your team can implement it all without me, that’s a good outcome and I’ll say so.
Honest fit
Not every website needs a technical SEO consultant. That’s exactly why I diagnose first, so neither of us spends months on the wrong problem.
Questions
Usually when something has gone wrong that your existing team can’t explain. A sudden traffic drop with no obvious cause, pages that won’t index, a migration that didn’t recover, or conflicting reports from different tools.
The other common trigger is scale — a site that worked fine at 5,000 URLs starts behaving unpredictably at 500,000, because problems that were invisible at small scale become structural at large scale.
An agency is built to deliver a defined scope of work across many clients, which is genuinely efficient for ongoing execution — content, links, reporting, campaign management.
A consultant is brought in for a specific problem that needs judgment rather than throughput. The practical difference is that the person diagnosing your problem is the person you actually work with, rather than a strategist who scopes the work and hands it to a delivery team.
That’s usually the arrangement. With full-stack and server-level experience I can write specifications your engineers can implement without translating them first, join technical calls, review implementations before they ship, and answer questions in whatever tracker your team already uses.
Both, depending on your platform, access and team. Where I have access I can implement directly. Where your developers own the codebase, I work alongside them — which is the more common arrangement on enterprise sites, and usually the right one.
Typically three to six weeks to a confirmed root cause, depending on site size, how much historical data exists, and how quickly I can get access to logs and analytics. Very large or multi-team sites can take longer simply because there’s more surface to rule out.
Implementation and validation run beyond that, on a timeline set by your development cycle rather than mine.
Yes — it’s one of the most common reasons I’m brought in. The first job is separating the possibilities: an algorithm update, a technical change that shipped without anyone connecting it to SEO, an indexing shift, a manual action or a competitor change.
Those look similar from a traffic graph and have completely different fixes, so the diagnosis matters more here than almost anywhere else.
Yes, both after a migration that lost performance and before one that hasn’t happened yet. Post-migration work means comparing what existed against what shipped — URLs, templates, internal links, markup and directives — because migrations rarely fail on redirects alone.
If your migration is still upcoming, that’s the better time to involve someone. Preventing the loss costs considerably less than recovering from it.
In most cases, once the cause is identified. “Crawled — currently not indexed” is a symptom with many possible causes: discovery depth, duplication, canonical conflicts, rendering, or quality signals.
The fix is straightforward once you know which one it is. Guessing at it is what wastes months.
By comparing what’s in the raw HTML against what’s in the rendered DOM, then checking what Google actually receives when it fetches the page. That usually surfaces the gap quickly — content injected too late, resources blocked, or a rendered version that differs from what a visitor sees.
Regularly. Large catalogs are where technical problems compound fastest — faceted navigation, variant duplication, crawl budget and template-level issues all scale with the number of products. Shopify, BigCommerce, Magento, WooCommerce, custom and headless builds.
A technical SEO consultant diagnoses why a website isn’t performing in search for reasons that sit below the content layer — how it’s crawled, indexed, rendered and structured — and then directs the work to fix it.
In practice that means analyzing server logs and crawl data, testing how pages render, mapping site architecture and internal linking, resolving canonical and indexation conflicts, and translating findings into specifications developers can implement. The distinguishing work isn’t finding issues — tools do that — it’s determining which issue is actually causing the problem.
Crawl budget is the amount of crawling a search engine will do on a site — how many URLs it fetches and how often it returns.
For a small site it’s rarely a concern. It becomes significant on large sites, particularly where filters, parameters or programmatic pages can generate far more URLs than the site has real content. When that happens, crawling gets spent on pages that will never rank while the pages that would rank are visited less often.
Crawling and indexing are separate decisions. Google can fetch a page successfully and still choose not to store it, and Search Console reports this as “Crawled — currently not indexed” without explaining the reason.
Common causes include content that’s too similar to other pages, conflicting canonical signals, pages buried deep in the architecture, content that only appears after JavaScript runs, or the page not clearing a quality threshold relative to what’s already indexed.
Server logs record every request made to your site, including every request from Googlebot — which URLs it asked for, when, how often, and what your server returned.
It matters because it’s the only source that shows what search engines actually did, rather than what a crawler simulation predicts they would do. When tools disagree with each other, logs are usually how the disagreement gets settled.
Start here
Send me the site and what you’re seeing: the traffic pattern, the timeline, what’s already been tried. I’ll tell you what I think is going on and whether it’s the kind of problem I can solve.
If the problem isn’t technical, I’ll tell you that too, before you spend anything
