Your Blog Post Went Live Monday Morning — Googlebot Didn't Show Up Until Week Three
A landscaping company in Torrance published a post titled "Why Your St. Augustine Grass Turns Brown in July" on July 1st. Good instinct — that's exactly when homeowners across the South Bay start Googling the problem. The post went live on schedule, sitemap updated, social share fired off. Nineteen days later, Search Console still showed it as "Discovered – currently not indexed." By the time Google finally crawled and indexed the page, it was July 20th. The searches had already peaked and started declining. The post ranked fine for exactly nothing, because it ranked for a question nobody was asking anymore.
This isn't a content problem. The post was well-written, locally specific, and answered a real query. It's a crawl problem, and it's one that hits home-services and trades sites harder than almost any other vertical — because these sites tend to be small, thin on historical authority, and built on platforms that never signal urgency to Googlebot.
Publishing on a Schedule Doesn't Mean Google Reads on a Schedule
Most owners assume that once a page is live and in the sitemap, Google finds it within a day or two. That's true for The New York Times. It is not true for a 40-page plumbing site with a domain that's six years old and gets crawled the way Google crawls anything it doesn't consider urgent — occasionally, and without hurry.
Google allocates something called crawl budget to every domain: a rough ceiling on how many pages Googlebot will fetch from your site in a given stretch of time, based on how much it trusts that new content on your domain is worth the trip. That budget isn't fixed. It's recalculated continuously from three signals, and almost every small trades site fails at least two of them.
Signal One: How Fast Your Server Answers, Not How Fast Your Site Loads
Googlebot has its own internal budget for how much total time it's willing to spend fetching pages from a given host. If your average response time (TTFB — time to first byte) is 900ms because you're on shared WordPress hosting running twelve plugins, Googlebot can complete far fewer fetches in the time it's allotted than it could on a host answering in 120ms. This isn't the same metric as your PageSpeed score. It's measured in Search Console's Crawl Stats report, under "average response time," and most contractors have never opened that report once.
Signal Two: Internal Links From Pages Google Already Trusts
Googlebot re-crawls pages roughly in proportion to how often it revisits pages that link to them. Your homepage and your Google Business Profile–linked location pages get crawled frequently because they carry backlinks and get direct traffic. A new blog post sitting three folders deep with no internal link from anything Google visits often is invisible until Google happens to re-crawl your sitemap — which, for a low-authority domain, might be every 10 to 20 days.
Signal Three: Sitemap Signals That Are Actually True
Plenty of CMS platforms auto-generate a lastmod timestamp on every URL every time the sitemap regenerates — whether or not the page changed. Once Google catches a sitemap lying about update dates (and it does track this), it starts discounting that sitemap's freshness signals entirely. At that point your actual new content gets no priority boost over your five-year-old service pages.
Why This Compounds Specifically for Trades Businesses
A national retailer publishing daily has enough backlinks and direct traffic that Google treats the whole domain as high-crawl-demand — new pages get picked up in hours. A South Bay HVAC company with 38 total pages and a domain that gets crawled in bursts doesn't have that luxury. Every new post competes with your own older, more-linked pages for the crawler's limited attention on your site. If your service pages for AC repair and furnace installation get hit weekly because they're linked from your nav and your GBP profile, and your blog sits in a folder nothing links to, Google will keep re-crawling the pages it already trusts and skip the new ones — indefinitely, not just for three weeks.
This is also why the "post 7x a week and let volume do the work" strategy backfires for a lot of operators. If every new post lands in the same low-priority folder with the same weak internal linking, you're not building seven chances a week to get indexed fast — you're building seven pages competing for the same trickle of crawl budget, most of which arrive too late to catch the search demand they were written for.
What a Site Built to Get Crawled Fast Actually Looks Like
The fix isn't publishing less. It's removing the reasons Google has to treat your new pages as low priority.
Static generation changes the response-time math entirely. A site built in Next.js or Astro and served from Cloudflare Pages answers requests in the 50–150ms range because there's no database query, no PHP execution, no plugin stack — the HTML is pre-built and served from edge cache. That alone lets Googlebot complete more fetches per visit, which means it comes back sooner. This is the actual mechanical reason a custom-built site outcrawls a templated one, independent of design or content quality.
New posts need a link from something Google already checks often. A cornerstone page — your homepage, your main service page, your GBP-linked location page — should link to the newest 3–5 posts in a "recent updates" or "latest from the field" module. That single change routes crawl priority from a page Google trusts into a page it hasn't seen yet. For a general contractor publishing project write-ups, this is the difference between a case study getting indexed same-day versus sitting unindexed through the entire bid cycle it was written to support.
Sitemaps need real, page-specific lastmod values — not a global timestamp that updates every time any page on the site changes. And on a domain with real crawl-demand problems, manually pinging Google's Indexing API or using IndexNow on publish forces an out-of-cycle crawl request instead of waiting for Google's own schedule to get around to you.
None of this is exotic. It's infrastructure work that has to happen before the content calendar matters at all.
The Content Cadence Only Works on a Site Built to Move That Fast
A seven-post-a-week publishing schedule is a strategy for winning search demand that spikes and decays in days — a burst pipe question in January, a brown lawn question in July, an EV charger install question the week a rebate gets announced. That strategy is worthless if your infrastructure takes three weeks to notice the post exists. The publishing cadence and the crawl infrastructure aren't two separate line items. One is useless without the other, and most agencies sell you the first while ignoring that the second was never built.
If your blog posts are going live and disappearing into "Discovered – currently not indexed" for weeks at a time, that's not a content problem you can write your way out of — it's an architecture problem, and it's worth a direct conversation with someone who'll pull your Crawl Stats report before touching your editorial calendar.