Discovery: getting a new site found at all
A deployed site is reachable, not discoverable. Google finds new domains through links and Search Console, and a new domain has neither. This hub covers the steps that create an indexing path, the verification choice that grants more access than it should, and the canonical mistake that quietly blocks pages you want indexed.
Discovery is the gap between a site existing and a search engine knowing it exists. Those are two separate events, and nothing about the first causes the second. A deploy makes a hostname answer requests, and it notifies nobody. Google finds new sites by following links from pages it already crawls, so a new domain with no inbound links gives it no route in at all. The default outcome is not slow indexing. It is no indexing, for as long as the site is left alone. Across the seven sites in this network, Google produced 1 click in 28 days, and each was live, verified as working, and submitted for ad network approval with no path into Google.
The order this stage breaks in
The failures here are sequential, which matters more than any individual fix, because each check is unreadable until the one before it holds. First there is no property, so there is no data. Then there is a property but the sitemap was never submitted, or never parsed. Then the sitemap is read but its URLs contradict the canonicals in the markup. Then the pages are genuinely indexed and still get no traffic, which is a demand problem wearing an indexing costume. Working the fourth before the first is the most common way weeks disappear. Our rule is to ignore ranking until an exact-phrase search in quotes returns the page.
Verification proves ownership and nothing else
A verified property does not cause crawling, indexing, or ranking. It unlocks the reports that tell you why, and an unverified site is still crawled normally, so verification buys visibility rather than reach. Prefer the Domain property, which covers www, apex, http and https in one place instead of splitting the data across four. It requires DNS verification, where Cloudflare users are offered a one click path worth reading before accepting: it is an OAuth grant over the whole DNS account, not one record in one zone. Switching Instructions for to Any DNS provider gives a TXT value you write yourself. The failure mode arrives months later, when someone tidies a DNS record nobody recognizes and the property silently un-verifies, taking every linked product's data with it.
Submitted is not the same number as discovered
Sitemap submission is a separate step, and the property looks finished without it. The useful reading is not that the status says Success. It is the gap between submitted and discovered counts a day later. Submitted is what your file claims, discovered is what Google accepted, and a gap means entries were rejected. The usual causes are URLs that redirect, URLs on a hostname the property does not cover, and URLs returning anything other than 200. Priority and changefreq are ignored, so skip them, and set lastmod from real modification times or omit it, because a build that stamps today on every URL trains the crawler to distrust the field.
The canonical that names a URL the host does not serve
This is the quiet one. The file on disk is anagram-solver.html, the host serves /anagram-solver and 308-redirects the extension away, and the canonical still names the .html version. You have declared the authoritative address of the page to be a URL that immediately redirects elsewhere, and crawlers resolve that contradiction conservatively. The test is mechanical: fetch every canonical and read the status code, because anything other than 200 is misdeclared, and a 308 in that position is a defect rather than a redirect working. The wrong URL is almost never in one place. It sits in the canonical, the og:url, the sitemap loc entry and the internal navigation, and fixing one of the four leaves the other three outvoting it.
Bing and Google are not running the same process
Bing indexes new domains markedly faster, which distorts how a new owner reads their first three months. Measured on 2026-09-07, about 92 percent of this network's organic traffic came from the Bing family, meaning Bing, DuckDuckGo and Yahoo, and roughly 6 percent from Google. That ratio does not persist and it is not permission to skip Google. It does explain why IndexNow feels like it works: IndexNow reaches Bing and does not reach Google, which does not consume it. Use it in addition to Search Console, never in place of it, or your Google indexing path is still zero while your dashboard looks busy.
Including this site
This site has been live since 2026-08-31. In the 7 days to 2026-09-27 it recorded 4 pageviews, from 5 sessions. We are publishing that because it is the point: a site can be deployed, verified, correctly canonicalized and indexed, and still be read by almost nobody. The honest response is to keep the number visible rather than wait for a flattering one.
Start here
Your site is deployed and Google does not know it exists. Nothing else in this hub matters until there is an indexing path at all.
Every guide in this hub, in order
The calculator that goes with this stage
12-Month Growth Projector. Once an indexing path exists, the question stops being whether pages get found and becomes how fast the traffic compounds. The projector defaults to 15 percent a month, which is strong for organic growth.