Short answer: not when they are built properly, and yes when they are not. The long answer is worth your time, because the difference is measurable and you can check it on any site running our plugin.
Search for us and you will find a Local Search Forum thread titled “Review Click Through Rate & Nearby Now DoorWay Pages”. The sentiment in threads like it runs to this:
“Not a silver bullet… Google isn't giving Nearby Now users a giant boost.”
Practitioner sentiment, Local Search ForumWe did not write that and we are not going to pretend it does not exist. It is a fair thing for a sceptical marketer to say, and the honest response is to explain exactly what these pages are, concede the part of the criticism that lands, and show what we do about it.
A doorway page is one of a set of pages built to funnel visitors to the same destination, where the pages differ from each other only trivially. The canonical example is the one everybody has seen: forty pages where the only thing that changes is the city name.
The test is not whether pages were generated by software. Nearly every large site generates pages. The test is whether the pages are meaningfully different from one another, and whether each one is genuinely about the thing it claims to be about.
This is a real risk and we are not going to soften it. A contractor who spins up forty city pages whose only per-city variation is a shortcode with a different city in it is squarely in the blast radius, and the 2024 core update demonstrably hit exactly that pattern for regional home-services sites. If that is what someone built with our plugin, the criticism is correct.
A properly built Nearby Now city page is not a template with a variable in it. It is a rendering of work that actually happened in that city — and almost nothing on it is shared with the page for the next town over.
Different addresses, different work, different dates. A check-in in Round Rock describes a job in Round Rock.
Taken at those addresses, by those technicians, that day. No stock, no reuse across cities.
Every check-in carries the latitude and longitude of the job, not of the office.
Different people, named, in that city.
First-party, long-form, written by those customers about those jobs. The single hardest thing on a page to fake or duplicate.
Real timestamps, in real sequence, updating as the crew keeps working.
A doorway page changes the city name. One of these changes the jobs, the photos, the coordinates, the customers, the review text and the dates — and keeps changing them, because the crew keeps working. There is no template underneath it to find.
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "CheckInAction",
"agent": { "@type": "Person", "name": "Marcus T." },
"location": {
"@type": "Place",
"address": {
"@type": "PostalAddress",
"addressLocality": "Round Rock",
"addressRegion": "TX"
},
"geo": {
"@type": "GeoCoordinates",
"latitude": 30.5083,
"longitude": -97.6789
}
},
"startTime": "2026-08-14T09:22:00-05:00",
"description": "Replaced a failed run capacitor on a three-ton
system in an upstairs closet, then checked
static pressure across the coil before leaving.",
"image": "https://example.com/checkins/round-rock-0814.jpg"
}
</script>
One check-in, marked up with CheckInAction
— schema.org's own successor to the deprecated type we used to emit. The city page
carries dozens of these, each with its own agent, coordinates, timestamp, description and
image. Compare two cities' markup on any site running our plugin and see how much of it
overlaps. That is the check, and we would rather you ran it than believed us.
What we will not claim: this markup does not produce star ratings in Google's results. Google's self-serving review policy makes reviews a business collects about itself ineligible for review rich results on that business's own site — for us and for everyone else in this category. What it does earn is entity and locality signal, and eligibility for the rich results still available, video being the notable one. Anyone promising you stars from first-party reviews is either mistaken or selling.
A city page with two check-ins behind it is thin, whoever built it. So we set a floor, published it, and warn inside the product when a city is below it.
| Band | Threshold | What to do |
|---|---|---|
| Insufficient | under 3 check-ins, or no reviews | Do not publish a page for this city yet. There is not enough of a record of work to say anything a homeowner could not get from your home page. |
| Thin | under 8 check-ins, or under 3 reviews | Hold the page. This is the band that looks like a doorway page to Google, because the jobs behind it are too few to make it read as genuinely about the city. |
| Adequate | 8+ check-ins and 3+ reviews | Publish. There is enough distinct work — different addresses, different photos, different customers — that the page is about the city rather than about the city's name. |
| Strong | 20+ check-ins and 8+ reviews, active in 90 days | Publish, and treat the city as a priority for rank tracking. Depth and recency are both present. |
These are not aspirational numbers written for this page. They are the thresholds the platform computes per city, and the same ones behind the warning that appears in the WordPress admin when a city page is published below the standard — “only 2 check-ins for Round Rock; Google may treat this page as thin”. The full document, written for agencies, is the city page quality standard.
The floor for publishing is 8 check-ins and 3 reviews. Below it, the honest answer is that the page has nothing to be about yet — and the fix is more jobs recorded in that city, which is work the crew is already doing.
Pick two cities on any site running our plugin and diff the markup. That is a better answer than this page.