When to get a technical audit
- Before or after a redesign or platform change, to protect rankings.
- When pages are not appearing in Google weeks after publishing.
- After an unexplained drop in organic traffic or leads.
- Before investing in content or links, to make sure new work will be seen.
- When taking over a website built by a previous agency or developer.
What the audit examines
Indexing status
We start with Google Search Console's page indexing report, which lists pages Google has indexed and pages it excluded, with a reason for each. Common reasons include:
- Excluded by noindex tag: a page tells Google not to index it, sometimes by accident.
- Blocked by robots.txt: a rule prevents Google from crawling the page.
- Crawled – currently not indexed: Google saw the page but chose not to index it, often because of thin or duplicate content.
- Discovered – currently not indexed: Google knows the page exists but has not crawled it yet.
- Duplicate without user-selected canonical: Google found several similar pages and picked one itself.
- Not found (404) and soft 404: pages that do not exist or appear empty.
We check whether each exclusion is intended. Excluding a thank-you page is fine; excluding your main service page is not.
Crawl of the full site
We crawl the website the way a search engine does, following every link. The crawl reveals:
- Broken internal links and links to redirected pages.
- Redirect chains and loops.
- Pages with missing, duplicate or overly long titles and descriptions.
- Pages with no H1 or several H1s.
- Orphan pages that no internal link points to.
- Pages buried many clicks deep.
- Canonical tags pointing to the wrong place.
- Images without alt text or with very large file sizes.
Rendering
Some sites load content with JavaScript. Google can render JavaScript, but content that appears only after a click, or that fails to load for a crawler, may not be indexed. We compare the raw HTML with the rendered page using Search Console's URL Inspection tool to confirm Google sees the important content and links.
Speed and Core Web Vitals
We review field data from real Chrome users where available, and lab tests from PageSpeed Insights for individual pages. We check Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift, then identify the specific causes, such as oversized images, render-blocking scripts or slow server response.
Mobile experience
Google indexes the mobile version of your site. We check that it contains the same important content, links and structured data as the desktop version, and that it is usable on a phone.
Duplicate content and URL versions
We check that the site resolves to a single version: https rather than http, and either www or non-www, with the others redirecting. We also look for the same content at several URLs, such as with and without trailing slashes or tracking parameters.
Structured data
We validate structured data with Google's Rich Results Test and the Schema Markup Validator, and check that the markup matches visible content. For local businesses, we confirm LocalBusiness details match the Google Business Profile.
Sitemaps and robots.txt
We check that the XML sitemap lists only indexable, canonical pages, is submitted in Search Console and stays within the limit of 50,000 URLs or 50 MB uncompressed per sitemap file. We review robots.txt for rules that block important pages or resources.
Security and server health
We check HTTPS across the site, mixed content warnings, server errors and response times.
How findings are prioritized
| Priority | Type of issue | Example |
|---|---|---|
| Critical | Blocks indexing of important pages | Noindex tag on service pages, robots.txt blocking the site |
| High | Wastes ranking strength or confuses Google | Duplicate URL versions, broken redirects from old high-value URLs |
| Medium | Weakens performance | Slow mobile pages, missing structured data, orphan pages |
| Low | Polish | Missing alt text on decorative images, minor title length issues |
Critical issues are fixed first, because nothing else matters if Google cannot index the pages.
What you receive
- An executive summary in plain language: the state of the site and the most important fixes.
- Detailed findings, each with evidence, affected URLs, the fix and how to check it worked.
- A prioritized fix list your developer can work through in order.
- A walkthrough call with you and, ideally, your developer.
Technical issues common on Phoenix business sites
Audits of local business websites in the Valley often find the same patterns:
- A staging or development copy of the site that Google indexed.
- Location pages created from one template, with almost identical content.
- Old URLs from a previous website that now return 404 errors while still receiving links.
- Contact forms and call tracking scripts slowing mobile pages.
- Image galleries of past projects with very large, uncompressed photos.
- A website builder adding duplicate pages, such as tag or category archives, that compete with real pages.
Example of a finding
Every finding in the report follows the same format, so it is easy to act on. A typical example:
Finding: 14 location pages are marked "Duplicate without user-selected canonical" in Search Console. Evidence: the pages share over 90 percent of their text and have no canonical tags. Impact: Google is choosing one page to index and ignoring the others, so most cities have no page in results. Fix: rewrite each page with location-specific content, or merge thin pages into fewer, stronger area pages and redirect the rest. Check: after recrawl, each kept page shows as indexed in the URL Inspection tool.
This format lets a developer, a writer or a business owner understand the problem, the reason it matters and what done looks like.
Tools we use
We combine Google's own data with independent tools:
- Google Search Console for indexing, crawl stats, Core Web Vitals and search performance.
- A site crawler to follow every link and record titles, headings, status codes, canonicals and depth.
- PageSpeed Insights and Chrome's Lighthouse for speed diagnostics on individual pages.
- The URL Inspection tool to see a page the way Google renders it.
- Google's Rich Results Test and the Schema Markup Validator for structured data.
- Server response checks for redirects, status codes and headers.
Using several sources avoids relying on one tool's opinion and grounds every finding in evidence.
Questions the audit answers
- Can Google find and index every page that matters?
- Is anything wasting ranking strength, such as duplicates or broken redirects?
- Are pages fast and usable on phones?
- Is the site structured so important pages are easy to reach?
- What should be fixed first, and by whom?
Technical audit versus complete SEO audit
A technical audit focuses on crawling, indexing, speed and site health. A complete SEO audit also reviews content quality, on-page optimization, local SEO signals, the Google profile, links and lead tracking. If you already know content and local signals are strong but results are weak, a technical audit is the right focus. If you are not sure where the problem is, start with the complete audit.
After the audit
Most fixes can be made by your developer using the instructions in the report. If you prefer, we can make the fixes or work alongside your developer. Once critical and high-priority fixes are done, the next step is usually improving key pages through service page optimization. For teams that want ongoing guidance rather than a one-time report, local SEO consulting includes reviewing technical changes before they go live.
What we need from you
- Access to Google Search Console, or permission to set it up.
- Access to Google Analytics.
- The website platform and hosting details.
- Any recent changes: redesigns, platform changes, new plugins or domain changes.
- Contact details for your developer, if you have one.