7 Technical SEO Checks for HVAC Plumbing Trades 2026

Technical SEO for HVAC, plumbing, and trades is the crawl, index, speed, and structured-data work that lets Google fetch service-area URLs at all. It is not a content score, it is not a GBP listing, and it is not a blog calendar. Screaming Frog, Sitebulb, Oncrawl, Lumar, Botify, JetOctopus, and ContentKing are the seven crawlers and monitors in this shortlist. US Tech Automations sits above them as the ticket layer that blocks a template deploy when indexability, 4xx, and canonical checks have not all passed.

TL;DR: Buy Screaming Frog if a desktop spider on a few hundred URLs is enough. Buy Sitebulb if you want a desktop crawl with clearer visualizations. Buy Oncrawl, Lumar, Botify, or JetOctopus when the site is JS-heavy or you need log files and scheduling. Buy ContentKing if the hole is real-time monitoring of a live WordPress template. Skip all seven if you have a handful of URLs you can click in an incognito window this afternoon.

Free crawl cap: 500 URLs according to Screaming Frog on the public spider page. A 420-URL HVAC site still fits the free cap. A 2,000-URL city×service map does not. That cap is the first buying fork, not a rank claim.

Crawl budget on service-area sites

Trade sites leak crawl budget on faceted city URLs, parametered booking widgets, and old offer pages that 404. Google Search Central's ecommerce guides tell stores to share product data, add relevant structured data, and design crawlable URL and site structure so Google can parse catalog pages, according to Google Search Central. A service catalog is not a SKU grid, but the same rule applies: if the spider cannot reach /ac-repair/mesa, the grader never gets a chance.

Zero-traffic pages: 96.55% according to Ahrefs (2023). Many of those URLs were never indexable. Technical SEO is the filter before on-page.

ROI questions belong on whether HVAC SEO is worth it. AI-answer work belongs on how trades get cited in Google AI. Job dispatch is a different buy: best HVAC software.

Key Takeaways

• Technical SEO for trades is crawl, index, canonicals, speed, and schema that does not fake NAP — not a content score.

• Screaming Frog and Sitebulb win desktop spiders; Oncrawl, Lumar, Botify, and JetOctopus win log files and JS; ContentKing wins live monitoring.

• Fail any template deploy that ships 4xx, noindex on keepers, or a canonical to the homepage.

• BEST_OF earn rate: 15.2% according to US Tech Automations (2026), on 12,514 live pages counted 2026-08-24.

• Zapier can POST a 404 CSV with retries; the shop still owns who may deploy the theme.

• Skip the ticket layer when a handful of URLs can be clicked by hand this week.

Who this is for

This page is for owners, office managers, and agencies who run WordPress or similar sites for HVAC, plumbing, and trades with service-area URL patterns.

Red flags: Skip Botify if Screaming Frog already finishes the crawl on a static template. Skip ContentKing if nobody will look at the alerts. Skip Oncrawl if you needed a £-class desktop licence this afternoon and the URL count is under 500.

Evaluation weights

Source: editorial weights, 2026-09-07.

Feature matrix

Source: vendor homepages, category facts 2026-09-07. Screaming Frog free cap as cited above. Other paid dollars: contact vendor.

Dated prices and TCO

Source: SEO retainers: $1,000–$5,000/mo according to WebFX (2026). Software: contact vendor except the Frog free cap.

Spider shortlist

Screaming Frog

Best fit: shops whose URL count is near or under 500, or who will buy the paid licence for a larger map and stay on a desktop crawl. Limitations: paid price is contact vendor here; no live monitor. Implementation: crawl, export Status Code and Indexability, ticket 4xx and noindex keepers. Primary evidence: screamingfrog.co.uk/seo-spider. Disqualify the free cap if the map is 2,000 URLs.

Sitebulb

Best fit: desktop crawls with hints and visualizations a non-engineer can read. Limitations: contact vendor; not a log-file platform. Implementation: crawl the service-area pattern, export hints, ticket template issues. Primary evidence: sitebulb.com. Disqualify Sitebulb if you already live in Frog and would only duplicate the crawl.

Oncrawl

Best fit: log-file SEO and cloud crawls on larger WordPress maps. Limitations: contact vendor; overkill for 200 URLs. Implementation: connect logs, crawl, prove Googlebot hit the city URLs. Primary evidence: oncrawl.com. Disqualify Oncrawl if Frog already lists the 4xx you will fix this month.

Lumar

Best fit: scheduled crawls and monitoring for agencies that run many trade sites. Limitations: contact vendor. Implementation: allowlist the domain, alert on 4xx, ticket the theme developer. Primary evidence: lumar.io. Disqualify Lumar if ContentKing already monitors the live template and the crawl is small.

Botify

Best fit: JS-heavy booking widgets and log-file proof that Googlebot never rendered the finder. Limitations: contact vendor; weaker than Ahrefs for keywords. Implementation: crawl, align logs, fix render, then hand keepers to content. Primary evidence: botify.com. Disqualify Botify if the theme is static HTML.

JetOctopus

Best fit: fast cloud crawls plus log analysis for large URL sets. Limitations: contact vendor. Implementation: crawl, slice by template, ticket 4xx by folder. Primary evidence: jetoctopus.com. Disqualify JetOctopus if Oncrawl or Botify already owns logs.

ContentKing

Best fit: real-time monitoring when a plugin update noindexes the blog or drops titles. Limitations: contact vendor; not a log-file crawler. Implementation: watch keepers, alert on noindex and title changes, ticket immediately. Primary evidence: contentkingapp.com. Disqualify ContentKing if nobody will acknowledge the alerts.

Schema and Core Web Vitals gates

Schema on a trade site should describe LocalBusiness or Service without inventing NAP. Core Web Vitals belong on the template, not on a one-off blog post. Neither is a crawler feature you buy instead of fixing 4xx. Put 4xx and indexability first. Then schema. Then LCP on the service template. A Botify crawl that proves render and a ContentKing alert that catches noindex are complementary; they are not two ways to skip the unique fact on the URL.

Worked example: 420-URL plumbing site

Worked example: a plumbing company with 420 URLs (8 services × 40 cities plus blog), a 14-day developer SLA, and Screaming Frog on the free 500-URL cap. The crawl finds 64 Status Code 404s on expired coupons, 11 keepers with Indexability = "Non-Indexable" because a security plugin added noindex, and 9 city URLs that canonical to the homepage. Engineering fixes the 64 404s in 8 days, removes noindex on 11 keepers, and sets self-canonicals on 9 cities. The gate is 0 404s on keepers, 420 indexable service-area URLs, and a human who signs the 11 noindex failures. Zapier, Make, or n8n can POST the Frog CSV, retry on 5xx, and keep a run history; the shop still owns who may deploy the theme, idempotency on URL, and retention of the crawl file.

7 Best title earn: 25.5% according to US Tech Automations (2026), versus 14.0% for "5 Best" on the 12,514-page count of 2026-08-24.

Pagination, tag archives, and author archives on a plumbing blog should be noindex, follow if they exist at all. The keeper list is services, cities you can staff, and a handful of guides that earn links. Everything else is crawl waste. If JetOctopus shows 800 tag URLs and 40 keepers, the tag templates are the project, not a new cloud crawler. If Lumar alerts on 200 title changes after a Yoast update, freeze deploys until ContentKing is quiet. Technical SEO for trades is mostly saying no to URL types the CMS will happily emit. Rebuild the keeper sitemap after every theme update. If Frog and the sitemap disagree, believe Frog, then fix the CMS toggle that re-added tags. A 14-day developer SLA that does not include a recrawl is a hope, not a gate. Recrawl, export Indexability, and only then call the sprint done. That recrawl is the whole point of paying for a spider instead of clicking ten URLs. If the second crawl still shows 11 noindex keepers, the patch did not ship — do not close the ticket. Take a screenshot of Indexability before and after so the developer cannot argue the first export was stale. Store both screenshots with the ticket id so the recrawl is auditable.

What a trade-site crawl should fail

Fail the crawl when keepers return 404. Fail it when a security plugin noindexes /ac-repair. Fail it when city URLs canonical to /. Fail it when the booking widget is the only path to a city and that widget is client-side JavaScript Googlebot never executed. Fail it when parametered sort URLs (?zip=) explode the sitemap. Do not fail it because a blog tag is thin — noindex the tag. Do not fail it because LCP is 3.1s on a page that is not a keeper — fix LCP on the service template after keepers are fetchable. Oncrawl logs that show Googlebot skipping /service/{city} are a render ticket, not a content ticket. ContentKing alerts that fire on title changes during a plugin update are a freeze-the-deploy ticket, not a "we'll mention it in the monthly."

A 2,000-URL map that still uses free Screaming Frog will silently miss 1,500 URLs. That is a buying error, not a Google penalty. Pay for the licence or move to a cloud crawler. A 420-URL map that pays Botify for log files it will not read is the opposite error. Match the spider to the map. Then staff the 4xx queue. JetOctopus and Lumar both schedule; neither deploys the WordPress patch. Sitebulb's visualizations help a non-engineer see duplicate titles; they do not write the unique fact. Keep technical and on-page as two queues with two owners.

Hreflang, international, and news sitemaps do not belong on a two-depot plumbing site. Neither does an XML sitemap that lists 404s. The sitemap should be the keeper list the crawl already passed. If Frog says 64 404s and the sitemap still includes them, you taught Google to fetch junk. Rebuild the sitemap from the indexable export, not from the CMS "all pages" toggle.

Frog CSVs in n8n versus a deploy gate

A shop can schedule a Frog or Lumar export, POST 4xx rows into GitHub or a sheet with Zapier, Make, or n8n, branch on 5xx, and Slack the developer. Those tools can support run histories, retries, error branches, and audit evidence when configured. The buyer must still design observability, idempotency on URL, escalation when the theme update reintroduces noindex, access controls, retention of crawl files, and maintenance. A proposed US Tech Automations design would open a ticket only when Indexability is indexable, 4xx = 0 on keepers, and canonical is self or intended, and would leave theme deploys behind a named human. It would not replace Screaming Frog and it would not claim a live ranking lift.

When NOT to use US Tech Automations: if ContentKing already pages the developer on noindex and the URL count is small, the monitor is enough. If you have a handful of URLs, click them. If the only hole is on-page copy, buy a grader, not a crawler ticket.

The homepage is the company index. When the seven technical checks are the job, price the gate rather than adding an eighth spider.

What tools do HVAC shops need for technical SEO?

A spider that covers every service-area URL, a way to see 4xx and noindex, and a monitor if plugins change live. Screaming Frog or Sitebulb for small maps; Lumar, Botify, Oncrawl, or JetOctopus for logs and JS; ContentKing for live alerts.

What software fits technical SEO for HVAC, plumbing, and trades?

The seven crawlers in this shortlist. None of them is a GBP editor or a content grader. Match URL count and JS complexity to the seat.

Which platforms should a trade site crawl in 2026?

The public service-area URLs, the blog, and the booking paths you actually want indexed. Do not waste crawl budget on faceted junk and expired coupons.

Do we need Botify if Frog already runs?

Yes, when the booking widget is JavaScript and you need log-file proof. No, when the theme is static and Frog already lists the 4xx you will fix.

Can n8n replace Sitebulb?

No. n8n moves the CSV. Sitebulb (or Frog) produces the crawl. Buy the spider for the dataset; configure n8n for the ticket.

Should we delay content until the crawl is clean?

Delay template deploys that ship noindex or 4xx. Do not delay unique facts on already-indexable keepers. Technical and on-page run in parallel once keepers are fetchable.