How do investor service-area pages escape Google's doorway classifier?

REI Spark is a B2B SEO platform run by a licensed California real estate agent (DRE #02006033) who rebuilt Fast Home Buyer California from 105 thin city pages into a 41-page hybrid hub-and-spoke set — 19 county hubs plus 22 city pages for the highest-volume California metros — and runs Yuba Home Buyer's three Yuba-Sutter city pages on a custom Next.js stack. Both sites were audited May 5, 2026 against the doorway-classifier framework this article describes. Most "city page SEO" advice frames the question as page count. Google's classifier reads what each page contributes. This sits within the entity-based SEO root post as the local-SEO-and-schema branch.

What does Google actually classify as a doorway page?

A doorway page is defined by primary purpose at the per-page level — whether the page exists to add genuine unique value to the user or to game search-query coverage. The test applies regardless of how many pages a site publishes.

Google's doorway-pages policy names the trigger as a primary-purpose test, not a count test. The classifier asks one question per page — does the page exist to add genuine value to the user, or to funnel users to the same downstream destination by gaming query coverage. A site can publish two hundred service-area pages and pass the test if each page adds unique local depth. A site can publish ten and fail if all ten are paragraph-rephrased boilerplate.

The most common operator misreading is that page count is the trigger. Fifty city pages, the assumption goes, must be too many. The classifier does not evaluate page count. It evaluates each page's primary purpose, then aggregates the verdict across the site as a whole. Doorway-page classification sits in a different policy category from cloaking, sneaky redirects, and scraped content — those are separate spam policies with separate triggers. Conflating them produces the wrong fix every time.

The practical implication runs forward to H2 #3. Operators who understand the test stop counting pages and start auditing what each page contributes that the others do not.

Why do most investor city pages qualify?

Most investor city pages qualify because the unique-attribute layer is paragraph-rephrased boilerplate. The dominant trigger pattern is a per-city template generator — a tool that ships identical schema and copy structure across cities by design, leaving operator customization the missing layer.

The trigger pattern is structural. A per-city template generator — Carrot's city-page expansion tool, a WordPress duplication plugin, or a thin Next.js dynamic [city] route with a shared body component — produces N city pages from one template with city-name swap. Each page emits identical schema, runs the same sections in the same order, and differs only in the city string and any paragraph the operator hand-rephrases. The classifier reads this as low-value, regardless of how many pages the site publishes.

Carrot's per-city generator is the most common case in the niche, and the behavior is a defaults trade-off, not a defect. The generator ships identical schema and copy structure across cities because that is what makes one-click city-page expansion possible — the platform optimizes for breadth and leaves customization as operator responsibility. Same pattern on WordPress with a city-page template plugin, on Squarespace section duplication, and on any custom stack running a single dynamic route across cities without per-page content blocks.

Three diagnostic signals an operator can run without paid tools. View-source diff — pull two city pages and diff the body HTML; if the unique span is under thirty percent of the document, the unique-attribute layer is too thin. Schema audit — if Service.areaServed lists every city the operator works in on every page, the schema is templated. GSC Coverage report — if a meaningful fraction of city pages return "Crawled — currently not indexed," the classifier has already decided. A May 2026 audit of five Carrot showcase sites from Post 6's continuity benchmark surfaced this directly: four of five ship only Organization and WebSite schema, with no Service, LocalBusiness, Person, or areaServed entity. The fifth — the heavily customized 412houses.com — ships full Service entities with twenty-eight named cities in areaServed plus a LocalBusiness anchor. Operator-customization-layer thesis at the schema level, the same one Post 7 raised at the citation level.

What unique value must a service-area page add to escape the classifier?

Pages need locality-specific entity attributes plus operator-specific local proof plus schema-side specificity to escape the doorway classifier. Each city page should encode at least one named neighborhood list, at least one operator-verifiable local proof, and a per-page Service.areaServed schema value.

Three concrete categories earn page-level uniqueness, and the test passes when a page carries at least one signal from each.

Locality-specific entity attributes are geographic sub-entities below the city level — named neighborhoods, school districts served, ZIP codes covered, local landmarks, and county-boundary nuance (which side of the line a property has to be on for the operator to buy it). A May 5, 2026 audit of Yuba Home Buyer's three city pages surfaced five named neighborhoods on Yuba City (Tierra Buena, Plumas Lake, South Yuba City, North Yuba City, Bridge Street) and two ZIPs (95991, 95993); six on Marysville (Yuba River, Linda, Olivehurst, Edgewater, Loma Rica, Browns Valley) and ZIP 95901; three on Olivehurst (Plumas Lake, Linda, Marysville) and ZIP 95961. Neighborhood lists do not overlap across pages.

Operator-specific local proof is the layer competitors cannot reproduce — recent transactions in that city, photos shot on-site, named local partners, and specific market-quirk knowledge. This is operator inventory rather than platform output. The audited YHB pages each carry the same DRE credential — DRE #02006033 surfaces in both the JSON-LD and the body copy on all three.

Schema-side specificity ties the on-page evidence to a structured-data anchor — a real LocalBusiness block distinct from a single corporate Organization @id, a Person entity carrying verified credentials, and a per-page Service.areaServed value listing only the cities the operator actually works in for that service. Post 3's Organization schema established areaServed at the corporate level; Post 8 extends it to the page-level Service entity — corporate areaServed declares the company's reach, page-level areaServed declares which cities the page is the canonical answer for. The bridge to Post 7's hyperlocal-fan-out finding: hyperlocal entity strength wins narrow fan-out queries because each city page contributes a locality-specific passage that survives passage-level deduplication. Generic templated city pages collectively contribute one passage's worth of retrievable content.

How do you use local entities (neighborhoods, school districts, ZIP codes) as page-level attributes?

Treat each city page as an instance of a Service-area page entity with three attribute layers — Root (every page has these), Rare (named neighborhoods, schools, ZIPs most competitors omit), Unique (operator inventory — recent named transactions, on-site photos, named local partners).

The Entity-Attribute-Value approach applies directly at the city-page level. Each city page is an instance of the Service-area page entity, and its content earns doorway-test immunity when its attribute layer reaches the right depth across three tiers.

Root attributes are the baseline — every page has these, so they cannot be the source of unique value. City name, primary service offered, operator entity, contact channel, brand chrome. Roughly seventy percent of any service-area page is shared template by word count.

Rare attributes are where most competitor pages stop. Named neighborhood list, named school districts, ZIP codes covered, county-boundary nuance, local landmark references. The May 5 YHB audit shows each Yuba-Sutter page carries between three and six named neighborhoods and one to two ZIP codes specific to its city — the rare-attribute layer is operator-verifiable on every page.

Unique attributes are operator inventory the competition cannot reproduce. Recent named transactions ("we bought a 1962 ranch in Plumas Lake on March 12, 2026"). Photos shot on-site for the page hero, not stock. Named title companies the operator typically closes with in that county. Specific local market quirks — probate court schedule, county-recorder turnaround, common local title issues.

The operator-side workflow at scale: start a per-city research file with neighborhood lists from the city's general-plan document and school districts from county GIS data. Cross-reference with the operator's own transaction log to surface three to five named recent transactions per city. Photograph one or two properties per city for the page hero. Draft the per-city unique blocks against this research, leaving the shared template for structural elements only. The same depth that earns doorway-test immunity earns hyperlocal fan-out wins — cash-buyer queries are city-modifier-heavy, low-volume, and reward operators who can prove genuine local presence.

Can templated city-page content scale safely, or do you have to write each one from scratch?

Templated city-page content scales when a shared root template carries about seventy percent of each page and per-city unique blocks carry the remaining thirty. The split is an operator rule descriptive of audited sites; below thirty percent, pages should consolidate.

The framework runs at two layers. Shared root template carries the structural elements — header, footer, navigation, brand sections, the "what we buy" service description, the contact form. Roughly seventy percent of each page by word count. Per-city unique blocks carry the locality-specific attribute layer from H2 #4 — neighborhood lists, school districts, ZIP codes, recent transactions, GBP-anchored local-pack signals. Roughly thirty percent of each page by word count, but one hundred percent of the unique-value signal the doorway classifier reads.

The seventy-thirty split is an operator rule descriptive of audited sites that pass the doorway test, not a published Google number. The figure reverse-engineers the natural ratio operator-customized sites exhibit — pages above thirty percent unique reliably index and rank; pages below reliably stall in "Crawled — currently not indexed." Treating it as a target to engineer toward rather than a pattern to preserve breaks the framework.

The consolidation calculus follows. If eighty templated city pages cannot each carry thirty percent unique content, the per-page unique-attribute layer is too thin to scale by expansion. The rational move is consolidation to fewer county-level hubs where the unique-value layer aggregates at the county tier — each hub carrying its named cities as sub-entities, with county-court process and county-specific market dynamics as the new attribute depth. Fast Home Buyer California ran this migration in 2025: 105 thin city pages consolidated to a forty-one-page hybrid hub-and-spoke set — nineteen county hubs plus twenty-two city pages preserved for the highest-volume California metros where city-level search intent outweighed county rollup. Per-page unique value rose materially against the pre-migration baseline.

Carrot's per-city generator does not natively support this consolidation pattern because the generator is built for one-page-per-city expansion — defaults trade-off, not defect. Operators whose unique-value layer is too thin to scale per-city can invest in the customization layer manually, consolidate to county hubs, or move to a stack that supports both expansion and per-page customization. The full migrate-or-stay strategic comparison sits in a forthcoming Quality Node post. REI Spark's custom Next.js websites for real estate investors are one path when the customization layer needs platform support the templated solution does not provide.

Worked example — YHB hyperlocal city pages and FHBC's hybrid hub-and-spoke consolidation

A May 5, 2026 audit found Yuba Home Buyer's three city pages and a five-page Fast Home Buyer California sample both pass the doorway test — per-city LocalBusiness on YHB, page-level Service plus AdministrativeArea or Place across FHBC's forty-one-page consolidated set.

The audit ran live against both production sites on May 5, 2026, with raw output preserved at C:\REISPARK\research\service-area-audit.json for traceability. Numbers stated as descriptive of the audit window.

Yuba Home Buyer hyperlocal — three city pages. Yuba City, Marysville, and Olivehurst each emit eleven JSON-LD types: BreadcrumbList, FAQPage, HowTo, ImageObject, LocalBusiness, Offer, Person, Place, RealEstateAgent, Service, WebPage. The schema-type signature is uniform across all three; the differentiation lives in the instance values. Yuba City declares Service.areaServed = "Yuba City" plus a city-specific LocalBusiness anchor; Marysville declares "Marysville"; Olivehurst declares "Olivehurst". DRE credential surfaces in JSON-LD on all three. Body word counts run 1,662 to 1,948. Sister-page body-copy overlap (3-shingle Jaccard) averages 0.47 — substantial shared template plus a per-city unique layer carrying three to six named neighborhoods and one to two ZIP codes per page with no neighborhood overlap across pages.

Fast Home Buyer California hybrid — five-page sample. Sacramento city, San Mateo (county hub plus city), and Fresno (county hub plus city) — picked to expose the hub-and-spoke contrast within the forty-one-page consolidated set. Schema differs by node type: county hubs add AdministrativeArea, city pages add Place. Both layers ship Service, Organization, Person, and per-page Service.areaServed. DRE credential surfaces in metadata, JSON-LD, and body copy on all five. Body word counts 1,311 to 1,919. Sister-page Jaccard averages 0.21 — meaningfully lower than YHB's 0.47, because hub and city pages serve different intents. The Fresno County hub aggregates the county; the Fresno city page sharpens the metro. The hybrid model pulls content angles apart by design.

Carrot showcase — five-domain doorway-classifier surrogate. The same five Carrot showcase domains from Post 6's Core Web Vitals audit re-audited at the schema layer. Four of five default-install homepages ship only Organization and WebSite. No Service, no LocalBusiness, no Person, no areaServed. The fifth — the Pittsburgh operator at 412houses.com — ships full Service plus LocalBusiness plus areaServed with twenty-eight named cities. Operator-customization-gap thesis Post 7 raised at the citation level, applied here at the schema level.

The point of the contrast is not that one model wins. YHB and FHBC both pass the doorway test, for different reasons. YHB passes through hyperlocal entity strength — full per-city LocalBusiness anchors, GBP verification, DRE credential on every page. FHBC passes through hybrid hub-and-spoke — the structure pulls intent apart between hub and city, forcing lexically differentiated content at scale. Both required a manual customization layer the operator built page by page. Neither came from a default install.

The doorway test is per-page, not a count. Most investor city pages fail because the unique-attribute layer is paragraph rephrasing; pages pass when each instance encodes locality-specific entity attributes backed by schema and operator-specific local proof. The action: pull two of your own city pages, diff them in view-source, and surface what each page contributes that the others do not. That diff tells you whether the right move is per-page customization, county-hub consolidation, or something hybrid. Return upstream to the entity-based SEO root post for the topical-authority context this diagnosis sits within. REI Spark's custom Next.js builds for real estate investors are one path when the customization layer needs platform support the templated stack does not provide.

By YK Kuliev, California DRE #02006033 — operating cash-buyer brand sites since 2018, REI Spark since 2025.