Sample layout. Not a real client.
Trade, city: the problem in one line
- Starting point
- Rank grid before any change
- What changed
- The one or two changes that moved it
- Result
- Rank grid after, and the change in calls
A site can look fine in a browser and still be hard for Google to read. A technical SEO audit checks the parts you can't see and tells you which problems are costing you search visibility.
No long contracts. You talk to Simon.
Map pack: electrical panel upgrade San Diego
A
B
C
Scientific SEO
A technical SEO audit inspects whether search engines can reach, load, read and index every page that matters, which has to happen before a page can rank, and delivers a ranked list of problems with the evidence for each. I run it as one part of a Scientific SEO Audit. Carrying out the repairs and keeping the site healthy afterward is ongoing technical SEO, which is separate work.
The audit follows the route Google takes, from finding a URL to storing the page. Crawling comes first: whether the robots.txt file (the file that tells crawlers where they may go) blocks anything it shouldn’t, and whether every important page can be reached by following links. Then the server’s responses, where I look for broken pages, chains of redirects, and pages that return an error code.
Next are the indexing and crawling signals: stray noindex tags, canonical tags (the tag that names the preferred version of a page) pointing at the wrong URL, and duplicate versions of one page. I check rendering: whether text and links are in the page’s HTML or appear only after JavaScript runs, which makes them slower and less certain to be read. I look at how pages load and display on a phone, since Google indexes the mobile version of a site. Last is structured data: whether schema markup is present, valid and consistent with what the page says.
A crawler following links from the home page produces one list of URLs. The sitemap gives a second, the pages the site says exist. The third, if you give me view access, is what Google reports it has indexed. On a healthy site the lists roughly agree, and I look for problems where they differ: pages in the sitemap that nothing links to, service pages that are linked and listed yet not indexed.
I rank each finding by what it costs you.
| Level | What it means | Example |
|---|---|---|
| Blocking | A page that should rank can’t be indexed at all | A noindex tag left on the service pages after a redesign |
| Weakening | The page is indexed and held back | Two URLs showing the same panel upgrade page, with links split between them |
| Housekeeping | Flagged by software, unlikely to affect calls | An image with no description on an old blog post |
Automated tools report all three levels in one list, which is how a sound site ends up with an alarming score. I list housekeeping items so you know I saw them, with a note that they can wait. I also mark each fix as a setting or a job for a developer.
A clean result means Google can read the site. Whether Google ranks it depends on what the pages say and how the business compares with its competitors. Judging whether your pages say the right things belongs to the content audit, and how AI assistants describe your company belongs to the AI visibility audit.
Order one when a redesign or a move to a new platform is followed by a fall in traffic, or when new pages never appear in Google. The other good moment is just before a rebuild starts, when the audit doubles as a list of what the new site must preserve, the core of site migrations.
If the site has been stable for years and its pages are indexed, the technical part is less likely to be where your calls are going.
Every engagement starts and ends with the same measurement.
Sample layout. Not a real client.
Not necessarily, because the score weights every warning by the tool's own formula, which isn't Google's. A site can score poorly over missing image descriptions and be fully indexed, or score well with its main service pages blocked.
Yes. Each finding names the affected URLs, shows the evidence and states the repair in terms a developer can work from, along with how to confirm it worked. I also mark which items need a developer and which are a setting in the site's admin area. If your developer disagrees with a finding, I want to hear why, because they may know something about the build that a crawl can't show.
It can when the drop followed a redesign, a platform change or a plugin update. A technical cause is then likely and the audit has a good chance of finding it. If nothing on the site changed, the cause may be a Google update or a competitor improving, and there may be no technical problem to find. In that case the audit rules the site out, which still narrows the search.
A site that is rarely edited doesn't need the same inspection repeated on a schedule, so the answer follows how often the site changes. The sensible times are before a redesign, when the audit doubles as a list of what the new site must preserve, then after the redesign and after a change of platform. A fall in rankings without an obvious reason is the other signal. Between those, the checks that belong to ongoing technical SEO are the better way to catch problems as they appear.
Your website address and a note on what changed recently are enough for me to say whether a technical audit is the right place to start.
Prefer to talk? Call (619) 675-7678, 9am to 6pm.