dblseo team
A technical SEO audit tells you whether Google can actually read, render, and index the pages you built to bring in calls. I run these for service businesses, and the same pattern shows up: the marketing budget is fine, the content is fine, and the site is quietly working against both. Technical SEO is the plumbing under the phone number. When it's clogged, everything you pay for downstream flows slower.
DBL SEO treats technical SEO as part of the same job as Local SEO, Google Ads, and lead tracking. That matters because a crawl issue on a location page can cost a multi-location client a whole market's worth of traffic without anyone noticing until the month's call volume looks wrong.
What the crawl actually has to get through
Before anything else, I ask whether Googlebot can fetch the pages at all. That means checking robots.txt for a stray disallow that blocks a folder someone added a year ago, then checking meta robots tags for noindex that got shipped with a staging template and never removed. A noindex tag on a location page is invisible in the browser. The page looks perfect, ranks nowhere, and nobody calls.
Rendering comes next. If the site is built on Next.js or a hybrid WordPress plus Next.js setup, I need to see what the bot sees after JavaScript runs, not what I see on a fast desktop. Service business sites often load their service lists, reviews, or form content client-side. If that content never renders server side, Google may index the shell of the page and skip the part that convinces a homeowner to call.
The audit also checks status codes across the whole site. A soft 404, where a missing page returns 200 with an error message on it, sends Google a page saying it's fine when it isn't. Those pile up during redesigns, and they're easy to miss unless you pull the crawl report. Redirect chains are the other common culprit. A page that hops three times before landing loses some signal on each hop, and the chain usually traces back to a URL change nobody documented.
I pull the crawl report into a spreadsheet and sort by status code before I look at anything else. That one pass tells me how much of the site is reachable and how much is lying to the bot. You can't fix indexing until you know what the crawler is actually getting back.
Checking how clean the indexing really is
Index bloat is a quiet cost. I pull the list of URLs Google has indexed and compare it to the list of pages that should be indexed. Tag pages, filter parameters, old promotional pages, and duplicate location pages built for cities you no longer serve all show up here. Every extra URL competes with the pages that matter.
Canonical tags are where this gets decided. A location page for a Fort Lauderdale office should have a self-referencing canonical that matches the URL. When the canonical points somewhere else by accident, Google credits the wrong page. On a multi-location site with pages built for markets across Florida, California, Texas, New York, and Oregon, one broken canonical rule can flatten every location page built from the same template.
I check sitemaps against the indexed list too. If a sitemap lists 400 URLs and 120 of them are noindexed or return 404, that's a message to Google that the sitemap can't be trusted. Clean sitemaps get crawled faster and more completely.
The constraint here is patience. Indexing changes take days to weeks to show up in the reports, so I don't re-check the day after a fix ships. I give the crawl a full cycle, then compare indexed counts against the target list. If the count hasn't moved, the problem is usually upstream of the canonical, back in the crawl access step.
Speed measured the way Google measures it
Core Web Vitals come down to three numbers: Largest Contentful Paint, Interaction to Next Paint, and Cumulative Layout Shift. I pull them from field data where Google has it (real users on real devices) and from lab tools where it doesn't. Field data is the score that counts. A site can look fast on a lab test and still fail in the field on a phone with three bars of signal.
For service businesses, the biggest speed costs I see are unoptimized hero images, third-party chat and tracking scripts loading before content, and fonts blocking the first paint. Images get compressed and converted. Scripts get deferred or removed. Fonts get preloaded.
Layout shift matters more than people think. If the schedule-a-visit button jumps while the page loads and someone taps the wrong spot, you lose the click and the lead. That's a conversion problem that also shows up in the audit.
One constraint I flag early: field data needs enough traffic to exist at all. A small market with low sessions may not have a field score, and in that case I work from lab data for that template and treat it as directional. The fix list doesn't change. The confidence level does.
How the site is built for the cities you serve
Local structure lives in the URL and the internal links. Each location page should have one clear, permanent URL pattern and a linked path from the homepage and from the service pages that apply there. Breadcrumbs help users and help Google understand where the page sits. When someone adds a new market as a subdomain instead of a subfolder without a plan, it fragments that structure.
I check the structured data on every location page: LocalBusiness markup with the address, phone, hours, and area served, plus Organization markup site-wide. The markup has to match what's on the page. A phone number in the schema that differs from the one in the header is a signal problem, not a shortcut. For medical and dental practices, the schema also needs the practice type right, and for law firms the attorneys and offices need to match the pages that describe them.
Internal linking is the part that's easy to ignore. If your Google Ads landing pages and your organic location pages link to different versions of the same offer, you're splitting signals across duplicate pages. One canonical destination per offer fixes it.
Where leads get lost between the form and the report
Technical SEO and lead tracking share the same fetch layer. If a form posts to a script that's blocked or a thank-you page that's noindexed, the lead still arrives but the conversion tracking may not. Call tracking numbers need to render correctly for bots too, otherwise the markup and the structured data disagree.
DBL SEO pairs analytics dashboards and rank tracking with the audit, so the fix list connects to calls, bookings, and revenue. The measurement sets the priority. A page with a broken form and a page with a slow image are both problems, but only one of them costs you a booked job today.
For multi-location clients, I build the report city by city. Showing the same core vitals number across forty locations hides the one market where a template update broke the hero image and the phone number both.
A fix list you can run in order
Technical SEO audit findings get prioritized, not dumped into a spreadsheet sorted by severity score. I order them by what they unblock and how fast they ship.
- Remove accidental blocks (robots.txt disallows, noindex tags, staging rules) so Google can crawl the pages that should rank.
- Fix canonical tags and redirect chains so each page has one address and no traffic leaks through hops.
- Compress images, defer non-critical scripts, and preload fonts to bring Core Web Vitals up in field data.
- Repair structured data to match the on-page business name, address, phone, and hours.
- Add internal links from the homepage and the relevant service pages to every location page.
- Clean sitemaps and re-submit them once the fixes go live.
Some of these ship in a day. Others need a developer sprint, especially when the template itself is the problem. A hybrid WordPress plus Next.js build can fix rendering quickly, because the service pages get pre-rendered while editors keep working in WordPress. Older WordPress sites often need a plugin cleanup before the vitals move.
The constraint on step four is the source of truth. The business name, address, phone, and hours in the schema have to come from the same place the site pulls them for the header and footer. When a practice changes its hours in one spot and not the other, I'd rather fix the data source than hand-edit the markup on forty pages.
Checking the audit actually moved something
Crawl errors and indexing counts tell you the fix landed. Rank tracking and GeoGrid heat maps tell you whether calls and clicks followed. I compare the same set of measurement points before and after the ship date: indexed location pages, field Core Web Vitals per template, impressions in each market, and Google Business Profile calls where that data is available.
The last step is the one people skip. Once the fixes are live, crawl the site again and confirm the old problems are gone. Then put a date on the calendar for the next pass. Templates change, plugins update, and new location pages get built by people who haven't read the audit. The second audit is where the first one pays off.