Technical SEO consulting

Data and access

Data collection starts with access: Search Console, Bing Webmaster Tools, analytics, server logs and the staging environment. From your team, this step needs the access and one conversation about how the site is built.

I run the crawl with Screaming Frog SEO Spider, in rendered mode as well, so you can see what search engines get in the raw HTML and what they get after JavaScript runs. The crawl produces the URL inventory: every reachable URL with its status code, canonical, indexability and internal links. On large sites the crawl runs on a server, not on my laptop, so a staging site behind your firewall or VPN can be checked too. When many teams and business units work on the same site and need segmented, role-based access, I set up the crawl to fit that need.

Server logs show what Googlebot, Bingbot and AI crawlers actually do: which URLs they request, how often, and what response they get. I analyze them with Screaming Frog Log File Analyser.

Search Console’s URL Inspection, Page indexing and Crawl stats reports show what Google indexed and what it left out. Bing Webmaster Tools gives the same for Bing.

Core Web Vitals field data comes from the Chrome UX Report, measured on real visitors. Lighthouse and WebPageTest measure in the lab: useful for debugging, but I keep the two apart. Ahrefs gives backlink and visibility data, DataForSEO keyword and SERP data. I pay for the tools; their cost is included in the hourly rate.

A checker I built myself runs through technical and entity issues. Tools automate finding issues. They don’t automate the diagnosis or the order of work.

Measurement: the baseline

The baseline records where we start: a fixed period, by page group (template, device, market), and any outside change in that period, such as a Google update or a campaign. These are the metrics:

• Indexed pages: how many of the valuable URLs are in the index.
• Time to index: how long it takes from publishing to being indexed.
• Crawl efficiency: how much of Googlebot’s activity goes to valuable URLs, and how much is spent on parameter, duplicate or broken URLs.
• Canonical match: whether Google picks the canonical you declared.
• Structured data: whether the markup is valid and the page is eligible for rich results.
• Server response (TTFB, DNS): how fast the server answers. This is the technical SEO benefit of speed: with faster responses, bots crawl more and sooner.
• Core Web Vitals (LCP, INP, CLS): loading, responsiveness and layout stability for real visitors. Google’s ranking systems take them into account, but the bigger effect shows up in user experience and conversion.
• Organic performance: clicks, impressions, click-through rate and position in Search Console.

Audit: what I check

The audit goes area by area through what blocks crawling, rendering and indexing. For every issue I look for the metric it shows up in and the cause behind it.

Crawlability. Crawlability means whether bots can reach your pages. I check crawl paths and crawler access, parameter handling and crawl budget, meaning whether Googlebot’s time goes to the URLs that matter. In internal linking I look at orphan pages and link depth: what sits deep in the site gets reached less often.

Indexability. Indexability means whether a page that bots reach can get into the index. The canonical is the main question here: is it absolute, does it point to itself, and does it match the one Google picks. In robots.txt I check the disallow rules and user-agent groups, in the XML sitemap that it lists only canonical, indexable URLs. For redirects I check the type (301 and 308 are permanent, 302 and 307 temporary), chains and loops.

Rendering. Rendering means what search engines see after JavaScript runs. I compare the raw HTML with the rendered DOM: if text, links or meta tags only appear through JavaScript, search engines see them later and several AI crawlers don’t see them at all. The fix is server-side rendering (SSR), static generation (SSG) or incremental static regeneration (ISR), and I check hydration and the caching layers too.

Speed. For technical SEO, speed is about server response time and the cost of rendering: the faster the response and the less client-side JavaScript, the more and the sooner search and AI bots crawl. On the CDN I check edge caching and that it doesn’t lock bots out. On the visitor side, Core Web Vitals show what causes poor LCP, INP or CLS on each template. Visitors leave a slow page and go back to the results sooner, and Google and Bing can treat that as a negative signal; Google acknowledged its use of click data in the 2023 US antitrust trial. How speed affects conversion is in the site speed and conversion case study.

Structured data. For structured data I check the JSON-LD markup: whether it matches the page content and passes Schema.org and Google validation without errors.

Site structure. For site structure I look at the URL hierarchy and crawl depth, and at the URLs and HTML your CMS templates generate. Information architecture, faceted navigation and the category system are content questions too, which I cover on the SEO content strategy page. Choosing and building the CMS is on the website implementation page.

International setup. On multilingual or multi-country sites I check the hreflang annotations and that they match the canonicals. Which market to enter with which URL structure and localization is on the international SEO consulting page.

Migration. For a migration I build an old-to-new URL map and a redirect and canonical plan, crawl staging before launch and watch the DNS cutover. A crawl runs before and after, so the two can be compared. The numbers from one of my own migrations are in the WordPress to Astro case study.

Prioritization and roadmap

Prioritization decides what comes first. I rank every issue on four criteria: how big the impact is, how much work it takes, how risky it is, and how sure we are of the cause. That becomes a technical SEO roadmap with owners, deadlines and dependencies, and every item says which metric it will show up in. This is the technical SEO strategy: not a list of issues, but the order of the fixes.

Implementation with your developers

Implementation runs through developer tickets. Every ticket says what to change, why, and what the acceptance criteria are, so a developer can start without coming back with questions. The tickets go into your backlog and sprints, and I tell you up front how much developer time they need, so they fit your capacity. On Shopify and WordPress I make the fixes myself; on other platforms I work with your developers while the tickets ship. The work doesn’t stop at the audit.

Checks before and after release

Checks run at two points: on staging before release and on production after it. I look for regressions, meaning whether the fix broke something else. If development runs through GitHub, the check is built into the release process and runs on every change. Otherwise a crawl runs before and after release.

Re-measurement and results

Re-measurement looks at the same metrics, on the same page groups, as the baseline. I set alert thresholds and allow for the time Google needs to recrawl and reprocess.

The technical results show first: faster and more indexing, faster server response, less wasted crawling, matching canonicals. The business results come later: more visibility, more relevant organic visitors, more organic conversions. We measure these with analytics data, and setting that up is covered on the web analytics consulting page. If traffic is large enough, I measure the effect with a template-level SEO split test against a control group. I don’t promise timelines. I tell you what we measure and what we compare it against.