Category 1 — HARD GATES: factors that determine whether the new site is crawled, rendered, and indexed AT ALL
Created 2026-06-25
Summary
Claim: Six hard-gate factors determine whether a page is crawled, rendered, and indexed at all. Fail one and the page does not enter the index — no amount of content quality compensates.
The six gates (each is a separate atomic entry):
- Reachability / 200 server response — Google hard gate — only 200-status pages are queued for rendering; non-200 (4xx/5xx) may skip rendering entirely.
robots.txtnot blocking — including JS/CSS — Google hard gate —robots.txtDisallow blocks crawling AND blocks rendering of JS/CSS; "Google Search won't render JavaScript from blocked files or on blocked pages".- No accidental
noindex— Google hard gate — when Googlebot seesnoindex(meta orX-Robots-Tag), it "will drop that page entirely from Google Search results"; stray stagingnoindexis the most common launch-killer; the most common launch error is a stray stagingnoindex. - Crawlable
<a href>links — Google does not followonclick,<button>, orjavascript:void(0)navigation — Google hard gate — Google follows only<a>elements with anhrefattribute;onclick,<button>,javascript:void(0)navigation is not followed. - Critical content not locked behind client-side JS — a conditional gate that bites hardest on new low-authority sites — Google CONDITIONAL gate — critical content locked behind client-side JS gates indexing for new low-authority sites; high-authority sites are largely fine; the bite is concentrated where it hurts most.
- Mobile version contains the content — mobile IS the indexed version — Content/structured-data/link parity between mobile and desktop is required — limiting links on the mobile version "can slow down discovery of new pages" and parity entries.
Confidence on each individual gate: Verified (Google docs). Grade A.
Source: Google Search Central documentation; compass_artifact research synthesis.
Confidence: High.
Caveat: Gates are binary and unforgiving. They are also cheap to fix if caught pre-launch. The launch checklist is Rule (Stage 0, pre-launch): clear the technical gates or stay invisible — 200, robots.txt not blocking JS/CSS, scan for stray noindex, real <a href> links, SSR/SSG for indexable content, responsive design for mobile parity.
Related entries
Related
- reference Content/structured-data/link parity between mobile and desktop is required — limiting links on the mobile version "can slow down discovery of new pages"
- reference Google hard gate — only 200-status pages are queued for rendering; non-200 (4xx/5xx) may skip rendering entirely
- reference Google hard gate — `robots.txt` Disallow blocks crawling AND blocks rendering of JS/CSS; "Google Search won't render JavaScript from blocked files or on blocked pages"
- reference Google hard gate — when Googlebot sees `noindex` (meta or `X-Robots-Tag`), it "will drop that page entirely from Google Search results"; stray staging `noindex` is the most common launch-killer
- reference Google hard gate — Google follows only `<a>` elements with an `href` attribute; `onclick`, `<button>`, `javascript:void(0)` navigation is not followed
- reference Google CONDITIONAL gate — critical content locked behind client-side JS gates indexing for new low-authority sites; high-authority sites are largely fine; the bite is concentrated where it hurts most
- reference Google mobile-first parity — structured data must be present on the MOBILE version; if it exists only on desktop, Google will NOT use it
- reference Google mobile-first parity — titles, descriptions, robots meta must match between mobile and desktop
- rule Rule (Stage 0, pre-launch): clear the technical gates or stay invisible — 200, robots.txt not blocking JS/CSS, scan for stray `noindex`, real `<a href>` links, SSR/SSG for indexable content, responsive design for mobile parity