Technical SEO Consultant: What I Look at in the First Hour

When I start with a new site as a technical SEO consultant, I don’t begin with a full crawl and a long export. I spend the first hour on triage: finding out whether anything serious is stopping Google from reaching, indexing or understanding the pages that matter to the business. Most of what I need is already sitting in the site’s own Search Console property.

I have worked in SEO and digital marketing for more than 16 years. The tools have improved, the questions have stayed the same. Below is the sequence I run, the Google tool behind each step, and what I write down. If you are hiring, use it to judge whether a candidate knows where to look.

What a technical SEO consultant checks first, and why

Technical SEO decides whether your content gets a fair chance at all. A page that Google can’t crawl, or treats as a duplicate of another URL, will not rank however well it is written. So the first hour is about finding blockers, not polish.

I split the hour into six blocks. The timings are rough: on a small brochure site some blocks take two minutes, while on a large shop the same hour only gets me a list of what to investigate.

Minutes 0 to 10: can Google reach the site?

I start with five or six URLs that make money, such as the home page, a key category and a product or service page. For each one I run a live test in the URL Inspection tool. Google’s help page explains that the normal result shows “the most recently indexed version of a page, not the live version on the web”, while the live test “fetches and examines the URL in real time.” Comparing the two tells me quickly whether something changed since Google last visited.

Then I open robots.txt. I am looking for rules that block whole templates, script or style folders, or a staging rule that was never removed after launch. I also check that the http and www versions of the domain redirect once, cleanly, to the version the business uses.

This is also where I correct one belief that comes up in almost every project. Google’s introduction to robots.txt says it is “used primarily to manage crawler traffic to your site” and that “it is not a mechanism for keeping a web page out of Google.” A disallowed URL can still be indexed if other pages link to it. If a page must stay out of search results, the page itself needs a noindex rule or a password, and Google has to be allowed to crawl it to see the noindex.

The most expensive technical problems I find are usually one line long, and they were added by someone trying to help.

Minutes 10 to 25: what Google has actually indexed

Next is the Page indexing report. It “shows how many URLs on your site have been crawled and indexed by Google”, with a list of reasons why other pages are not indexed.

The first thing I tell clients here is not to panic about the grey bar. Google is clear: “You should not expect all URLs on your site to be indexed, only the canonical pages.” It even answers the question “Is it OK if a page isn’t indexed?” with “Absolutely.” Filtered URLs, duplicates and old redirects belong outside the index.

So I don’t read the total. I open each reason and look at sample URLs, asking one question: is there anything here that should be ranking?

The reasons I read first

• URL marked “noindex”. Fine for thank-you pages and internal search. A problem when a category template carries it.
• URL blocked by robots.txt. Fine for areas you don’t want crawled. Google notes this “does not guarantee that the page won’t be indexed through some other means.”
• Crawled, currently not indexed. In Google’s words, “The page was crawled by Google but not indexed.” When important pages sit here, I look at content quality and duplication, not at technical settings alone.
• Discovered, currently not indexed. The page “was found by Google, but not crawled yet.” On a large site, many key pages here make me think about internal links and crawl capacity.
• Duplicate without user-selected canonical. Google found duplicates and chose for itself. That leads straight into the next block.
• Server error (5xx), Not found (404), Soft 404, Redirect error. I check whether the affected URLs are real pages that users and links still reach.

Minutes 25 to 35: canonicals and duplicates

Back in URL Inspection, for each money page I compare two fields. The help page describes the “user-declared canonical” as the canonical your page explicitly declares, and the “Google-selected canonical” as “the page that Google selected as the canonical (authoritative) URL” among similar pages.

If they match, good. If they don’t, Google is telling you it disagrees with your setup, and the page you care about may not be the one shown in results. The usual causes I find are parameter versions of the same page, products reachable under several category paths, and canonical tags pointing at redirected or noindexed URLs.

With one clean URL per page and consistent internal links, these disagreements mostly disappear. That is the logic behind our SEO website structure work.

Minutes 35 to 45: Core Web Vitals and page experience

Speed questions come up in every first call, and I try to answer them with field data, not with one lab score. The Core Web Vitals article on web.dev gives the thresholds I check against:

The same page recommends measuring at “the 75th percentile of page loads, segmented across mobile and desktop devices.” So I look at groups of pages by template, on mobile and desktop separately, in Search Console’s Core Web Vitals data, and then test one URL from each failing template in PageSpeed Insights to see the likely cause.

In the first hour I only note which templates fail, and on which device. The fixes need a developer and come later, as tickets.

Minutes 45 to 55: crawl health and the server

For large sites I open the Crawl Stats report. It shows total crawl requests, total download size, average response time and host status, which “describes whether or not Google encountered availability issues when trying to crawl your site.” It also breaks requests down by response, file type, purpose and Googlebot type.

I read it for trends: response time climbing, server errors, or crawling spent on URLs that shouldn’t exist. Google says the report “is aimed at advanced users” and that with fewer than a thousand pages “you should not need to use this report.” I agree, and on small sites I skip this block and spend the time on content and links instead.

When the report shows something odd on a big site, the next step is the server’s own logs, which show every request rather than a summary. That is a separate job: our log file analysis service exists for exactly that.

Minutes 55 to 60: the triage note

The hour ends with writing, not more checking. A long list of crawler warnings helps nobody. A note with three to five ranked issues, each with its evidence and a plain-language reason, can be acted on the same week.

Once fixes go live, Google’s own advice in URL Inspection applies: you can request indexing for a changed page, but “Indexing can take up to a week or two”, there are daily limits, and “Submitting a request does not guarantee that the page will appear in the Google Index.” For many URLs, a sitemap is the better route. If a migration or relaunch is involved, check the same keywords before and after the move, so you can tell a real loss from normal movement.

How to find a technical SEO expert who works this way

If you are asking who the experts in technical SEO consulting are, titles won’t tell you. Google’s page on what a good SEO does is a good starting filter. Then ask the candidate to talk you through their first hour on your site. Listen for three things:

1. They start from Google’s own data. Search Console, URL Inspection and field data first, third-party crawls second.
2. They separate normal from broken. Someone who calls every non-indexed URL an “error” will sell you work you don’t need.
3. They write it down. You should receive evidence and reasons you can hand to a developer, not a score.

Ask for read-only Search Console access for the first look, and keep ownership yourself. A good consultant can do the whole first hour with that.

What I do after the first hour

The triage tells me whether the site needs a full audit, a few targeted fixes or nothing technical at all. When the technical side is fine and the problem is content or links, I say so.

When deeper work is needed, it usually becomes a written technical SEO audit: crawling, indexing, rendering, structure and speed, with fixes in priority order. I charge by the hour, with no fixed packages, so a small site with one clear problem pays for one clear fix. You can see my background and certifications on my profile page.

FAQ

What does a technical SEO consultant do?

A technical SEO consultant finds and explains what stops search engines from crawling, indexing and understanding a site: blocked pages, duplicates, canonical problems, slow templates and server issues. The output is a prioritised list of fixes with evidence, written so a developer can implement it. Good ones also tell you when the technical side is not your problem.

Who are experts in technical SEO consulting?

Look for people who can explain Google’s own tools in plain language and show how they reached each conclusion. Ask them to walk you through how they would read your Page indexing report and your canonical fields in URL Inspection. Experience with your platform and site size matters more than any badge.

How do I find a technical SEO expert I can trust?

Start with Google’s published questions for hiring an SEO, then ask for a sample of a written finding. Give read-only Search Console access for the first review. Be wary of anyone who treats every non-indexed URL as an error or promises results by a date.