We Launched a New Website From Zero: What Google Indexed in the First 30 Days

Status: Study protocol complete; launch evidence and Google Search Console exports required. Not published as a results case study.

Updated: 12 August 2026 Author: VITON13 Research editorial desk Category: Google Search / Original Case Study Expected reading time after results: 14–18 minutes

Direct answer

VITON13 cannot yet make a defensible claim about what Google indexed during the first 30 days of a new-site launch. The repository contains development history, but no authenticated launch record, day-zero URL inventory or matching Google Search Console export. Those are different kinds of evidence. This page therefore publishes the study design, definitions, timeline template and data contract before any result is written.

The finished case study will join four independent evidence streams:

1. a frozen list of canonical, indexable URLs available at launch;
2. daily Google index-status observations from Search Console URL Inspection;
3. finalized Search Analytics impressions and clicks;
4. sitemap, deployment and verified Googlebot event records.

It will report discovery, crawling, indexing and search visibility separately. A sitemap submission will not be called indexing. A Googlebot request will not be called indexing. An impression will not be treated as proof that every page was indexed.

What Google’s documentation establishes

Google describes Search as three distinct stages: crawling, indexing and serving results. A page can be discovered without being crawled, crawled without being indexed, or indexed without receiving an impression for the observed queries.

The Page indexing report shows indexed and non-indexed counts for URLs known to Google, but Google warns that immediate indexing and 100% coverage are not appropriate expectations. Legitimate duplicate, alternate, redirected or intentionally excluded URLs can remain outside the index.

URL Inspection can report the indexed version, discovery evidence, crawl time and Google-selected canonical for a specific URL. Its live test checks whether a page appears indexable now; it does not predict canonical selection and does not guarantee inclusion. The URL Inspection API returns index information for authenticated properties, but not a live indexability test.

Submitting a sitemap is a hint, not an indexing guarantee. Google recommends listing canonical URLs and using accurate lastmod values. The general-purpose experiment will not use the Indexing API, because Google limits that API to qualifying JobPosting and livestreaming event pages.

The research question

For a new, publicly accessible VITON13 web property launched from zero, how did Google discover, crawl, index and begin serving its canonical pages during the first 30 complete days?

Pre-registered hypotheses

• The homepage and pages linked directly from global navigation will be discovered before deeper pages.
• Sitemap presence alone will not predict the exact day a URL becomes indexed.
• Some technically indexable URLs will remain non-indexed at Day 30, and their reported reasons will be more useful than a single coverage percentage.
• First impressions may occur later than the first indexed observation because index presence and search demand measure different things.

These are hypotheses, not findings. They remain in the record even if the observations contradict them.

What “Day 0” means

Day 0 is not the date of the first Git commit, domain purchase or private preview. It is the earliest timestamp at which all of the following are true:

• the production hostname returns the intended public site;
• the homepage is accessible without authentication;
• the launch URL inventory has been frozen;
• robots directives and canonical tags have been archived;
• the production sitemap is available;
• the Search Console property is verified;
• the study clock and timezone have been recorded.

If these events occur on different dates, the report will show each timestamp and use the final qualifying event as Day 0. The primary timeline uses UTC. Search Analytics exports retain Google’s documented Pacific Time reporting boundary and are not silently relabelled as UTC.

Cohort definition

The denominator is the frozen Day-0 set of canonical HTML URLs that return a successful response and permit indexing. It excludes:

• redirects and error pages;
• authenticated account and administration routes;
• API, feed and file endpoints;
• URLs with noindex;
• parameter variations and duplicate alternates;
• staging, preview and localhost hosts;
• URLs published after Day 0.

Pages added during the 30-day window form a separate post-launch cohort. Combining them with the launch set would allow denominator growth to obscure what happened to the original site.

Evidence model

The report will prefer URL-level inspection for the fixed cohort. Aggregate Page indexing totals are preserved as context because they may include URLs outside the cohort and their example list can be limited.

Collection schedule

The primary observation days are Day 1, 3, 7, 14, 21 and 30. A full daily snapshot is preferred; milestone reporting makes the article readable without hiding intermediate records.

Search Console can report with a delay. Google’s performance-data guidance says data is typically available after two or three days. The study will wait for finalized values and record the extraction date rather than treating a temporary zero as a final result.

Metrics and calculations

Primary outcomes

• Indexed launch URLs: count of unique Day-0 cohort URLs whose authenticated inspection verdict reports index presence at the snapshot.
• Index coverage: indexed launch URLs divided by all eligible launch URLs.
• Time to first indexed observation: first positive inspection timestamp minus Day 0. This is an upper-bound interval, not the hidden internal indexing timestamp.
• Median observed time to index: median across indexed cohort URLs, reported with the inspection cadence.
• Unresolved Day-30 reasons: URL count by Google-reported coverage state.

Secondary outcomes

• sitemap discovery and last-read timestamps;
• first verified Googlebot request by page;
• impressions and clicks by date and page;
• first observed non-branded and branded query groups;
• Google-selected versus user-declared canonical agreement;
• status, robots, canonical or content changes during the window.

The report will not publish an average position without its date range, aggregation and query/page scope. The Search Analytics API can omit some detailed rows and returns top data under internal limits, so query-level tables will be labelled as reported rows rather than a complete universe of searches.

Timeline template

No cell below will be pre-filled with invented results.

Narrative rules for each milestone

Every milestone entry will contain:

1. what changed since the preceding observation;
2. which evidence records support the change;
3. which intervention, if any, happened beforehand;
4. plausible alternative explanations;
5. what remained unknown.

Post-hoc technical fixes will be marked on the timeline. A later improvement will not automatically be attributed to the preceding change: this is an observational case study, not a randomized causal experiment.

Planned tables and visualizations

1. Index-status timeline. Six milestone bars showing indexed, not indexed and not yet observed launch URLs.
2. Discovery-to-index intervals. One row per launch URL with sitemap, verified crawl and indexed-observation timestamps.
3. Day-30 status reasons. Google coverage states with URL counts and manual diagnosis notes.
4. Search visibility timeline. Finalized impressions and clicks by reporting date, with incomplete days excluded.
5. Canonical agreement table. User-declared and Google-selected canonical pairs for exceptions.
6. Change-event overlay. Deployments, sitemap changes, internal-link changes and incidents displayed without causal language.

Data required from VITON13

DATA REQUIRED

Identity and launch
- production hostname and exact launch timestamp
- evidence that the public site was reachable at that time
- Search Console property identifier and verification date
- primary timezone and reporting timezone

Day-0 cohort
- canonical URL inventory
- HTTP status, indexability, canonical and robots directives
- page type and navigation depth
- sitemap membership and first publication timestamp

Google Search Console
- URL Inspection exports for Day 1, 3, 7, 14, 21 and 30
- Page indexing summary snapshots and reason counts
- sitemap submitted/read timestamps and discovered URL counts
- finalized Search Analytics exports by date, page and reviewed query

First-party operations
- verified Googlebot/CDN logs for the same window
- deployment and content-change log
- robots.txt and sitemap snapshots
- outage, WAF, rate-limit and redirect-change timestamps

Security
- never commit OAuth credentials, tokens or raw personal data
- redact sensitive query strings and private routes

The Git repository’s first commit may help reconstruct development chronology, but it is not accepted as the production launch timestamp. No Search Console credential or private export is present in this research package.

Limitations

This will be a single-site case study. Its launch cohort, authority, content, links and infrastructure will not represent every new website. Inspection snapshots observe states at intervals and cannot reveal the exact moment Google’s internal state changed. Search Console may revise recent values and does not guarantee every detailed query row. A crawler request is not an index record. Site changes during the window introduce confounding, while making no changes for 30 days may be operationally unreasonable.

The published conclusion will therefore describe what happened to this defined VITON13 cohort under documented conditions. It will not promise a universal indexing time.

FAQ

How long does Google take to index a new website?

There is no guaranteed duration. Google says new URLs can take time to discover and crawl, and even technically eligible pages are not guaranteed to be indexed. This study will report observed intervals for one frozen cohort, not a universal deadline.

Does submitting a sitemap index every URL?

No. Google calls sitemap submission a hint. It helps discovery and communicates preferred canonical URLs, but it does not guarantee crawling or indexing.

Is site:example.com an accurate index count?

It is not the primary measurement for this study. Authenticated URL Inspection responses for a fixed cohort and Page indexing reports provide more suitable property evidence. Search-result checks may be recorded only as supplementary, dated observations.

Can we request indexing for every page through an API?

Not through Google’s general Indexing API. Google documents that API for pages with qualifying JobPosting or livestreaming event markup. For many ordinary new pages, Google recommends a sitemap; individual URL Inspection requests have limits and do not guarantee inclusion.

Does “URL is on Google” guarantee impressions?

No. Google describes index eligibility and serving results as different stages. An indexed URL still needs a relevant query and sufficient serving signals to appear, and an inspection verdict does not promise placement.

What if fewer than 100% of eligible URLs are indexed on Day 30?

The report will examine each status reason before judging it. Some non-indexed states may be legitimate, while unexpected canonical, quality, crawl or server issues require diagnosis. The denominator and reasons matter more than a vanity percentage.

Sources and editorial accountability

Method claims link directly to Google Search Central, Search Console Help and the Search Console API documentation. The dated, annotated register is stored in sources.md. VITON13 operational claims will cite archived first-party records when those records exist. The protocol has no sponsor and no affiliate relationship; corrections will be logged in the final report.

Update plan

Freeze the protocol before Day 0. During collection, append observations without rewriting hypotheses. After Day 30, wait for finalized performance data, run the reproducibility checks, complete fact review, record deviations and only then replace the protocol status with results. Review the finished case study every 90 days for documentation changes while preserving the original dataset.

Quality score before data