Technical SEO Consultant
Crawling, indexing, migrations and rendering. The work that decides whether anything else you do in search will land. I have recovered a site from a Google manual action, taken two JavaScript cricket platforms through to server rendering and past the Akamai layer in front of them, and spent a lot of time in log files finding out what Google is really doing.
Companies and sites I have worked on
What I work on
Crawl and index diagnosis
Log files first, where logs exist. They tell you where Googlebot actually spends its time, which is usually nothing like where you assumed. Everything else tells you what you hope is happening.
Site migrations
The riskiest thing you can do to a site. Redirect mapping, indexation monitoring, and someone watching the numbers for weeks after launch instead of closing the ticket on day one.
Manual action recovery
A manual action does not tell you which pages caused it, so working that out is most of the job. Then a proper cleanup, a reconsideration request, and fixing the thing underneath so it does not come back.
JavaScript rendering and SSR
Crawl the site twice, once with rendering on and once off, and the gap between them is the problem. Usually it is content that only exists after hydration, navigation built on click handlers instead of real links, or a canonical injected too late to be trusted. I have taken two JavaScript platforms through to server rendering.
Architecture and internal linking
Page depth, crawl paths and template logic looked at together, because these problems compound. Usually paired with an internal linking framework.
Working with engineering
On a big site the useful unit of work is the template, not the page, so I specify SEO into templates and platform features alongside the engineering team. Findings go over as prioritised tickets with the reasoning attached, because an audit that arrives as a spreadsheet of 200 issues gets ignored.
What I check on a JavaScript site
Rendering problems are the ones that hide best. Everything looks right in a browser, the tools report no errors, and Google is quietly getting a different page. These are the eight checks I run, roughly in this order. Most of what I know about them came from crex.com and cricket.one, two JavaScript cricket platforms that ended up server rendered behind Akamai.
Rendered HTML against raw HTML
Crawl the site twice, once with rendering switched on and once off. The gap between the two crawls is the list of things Google might never see, and it is usually bigger than anyone expects.
Links that are actually links
Anchor elements with a real href, not a div with a click handler. The second works perfectly for a user and does not exist for a crawler. Same for infinite scroll: without paginated URLs behind it, everything past the first screen is undiscoverable.
The rendering strategy itself
Client side, server side, static, or prerendered at build time. This is the highest leverage decision on a JavaScript site and it belongs to engineering, so the job is arguing for the right one with evidence rather than filing a ticket. Both cricket platforms I worked on ended up server rendered.
Metadata that survives rendering
Titles, canonicals and robots tags injected on the client. Google does process them after rendering, but a duplicated or late canonical gets discarded, and then Google picks its own instead of yours.
Hydration mismatches
When the server HTML and the client render disagree, the framework can throw the server markup away and rebuild it. What got indexed and what users see stop being the same page, and nothing errors visibly.
Status codes the app cannot send
A single page app answers 200 for routes that were never real, because the server does not know the route is invalid. Google files those as soft 404s, and at scale that is where crawl budget goes.
Resources Googlebot needs
robots.txt blocking the JavaScript bundles or the API calls the page renders from. The page looks fine in your browser and renders empty for Google, which is a hard problem to spot from the inside.
What the edge serves a bot
CDN rules, bot detection and challenge pages handing Googlebot something different from a browser. I have worked through this on Akamai sitting in front of two cricket platforms. Invisible unless you go looking for it specifically, because everything is fine from your own machine.
How I run a technical audit
The order I go in, and why that order.
Start with the crawl, not the tool score
How does Google find your important pages, where is crawl attention going instead, and which sections are structurally hard to reach. A crawler and a log file answer this. A score out of a hundred does not.
Separate technical from content
Not every ranking problem is technical, and treating a content problem as a crawl problem wastes months. I split crawl, indexation, rendering, duplication and quality signals before recommending anything.
Check what the crawler actually receives
On a JavaScript heavy site I want to see the rendered HTML, not the source and not the browser view. If the content, the links or the metadata only exist after hydration, that is the finding.
Look at architecture and crawl together
Site structure, internal linking, template logic and page depth are one problem wearing four hats. Fixing one and ignoring the others usually moves nothing.
Rank the fixes by what they are worth
Grouped by impact, risk and effort, so your team knows what to do first and what can wait. The list is short on purpose.
"Technical SEO is not about finding more errors. It is about working out which of them is actually costing you traffic."
Technical work I can point at
Three pieces of technical work from the last few years, with the company named. The full write ups are on the homepage.
Getting a site out of a Google manual action
Diagnosed what triggered it, cleaned it up, then rebuilt the architecture so it would not happen again.
Server rendering and Akamai bot handling on two cricket platforms
crex.com and cricket.one are JavaScript applications behind Akamai. Getting them rendered for crawlers, and getting Googlebot cleanly through the edge, was the job. The two migrations came with it.
hreflang across five English speaking markets
Subdirectory architecture on one domain for the UK, Ireland, Nigeria, South Africa and India.
Frequently Asked Questions
Something is not getting indexed and nobody can tell you why
Send me the site and what you have already checked. I will tell you where I would look first, whether or not we end up working together.