Plugin Health Reporting

There are two questions worth asking about the city pages on your website, and they have to be asked in that order.

Is the content actually on the page? Not "does it look right in my browser" — is it in the HTML the server sends, where a search engine can read it?

And how often is it seen?

Most reporting skips straight to the second question. That is how a business ends up with a tidy monthly chart of a page that Google has never been able to read a word of.

So we built both halves. Plugin Health Check answers the first question in about ten seconds. The rebuilt Page View reports answer the second, one month at a time, with people and bots finally counted separately.

Plugin Health Check

Give it the address of a page on your website. It fetches that page from our server, parses the HTML, and hands back a checklist of what Nearby Now is actually putting on it.

It does not run JavaScript, and that is the whole point.

A headless browser would load the page, execute the scripts, watch the reviews appear, and cheerfully report that everything is fine — on exactly the pages where it is not. A search engine crawler reads what the server sends. So does this. If the content is there, a crawler can read it. If the container is empty until a browser runs scripts, a crawler gets an empty box, and the tool says so in those words:

Content is in the page source — Fail. No. The only Nearby Now content on this page is written by JavaScript after the page loads.

A crawler fetching this URL gets an empty container. Every review and check-in on it is invisible to search — this is the single highest-value thing to fix.

That one check has been the answer to more support tickets than anything else we ship.

What the checklist covers

• Whether the page loaded, and where it redirected to — every hop in the chain, listed
• Which Nearby Now shortcode rendered, and which generation of the plugin produced it
• How many reviews and check-ins came back
• Whether every JSON-LD block parses, and which @type values it carries
• Whether the invalid UserCheckins type is present — a real schema error we still find on older installs
• Whether the map is there, and which map it is
• Whether the content is in the page source, or written by JavaScript
• How much of the page is ours, by weight

Every line comes back as Pass, Warning, Fail or Info — an icon and a word, not just a colour — and anything that is not a pass carries the next step alongside it. "JSON-LD failed to parse" and nothing else just moves the problem; the person reading it usually is not the person who can read JSON, and what they need is a sentence they can forward to whoever can.

Detection by parsing, not guessing

The tool reads the page's actual structure rather than searching for text. Class names are matched as whole tokens, so nnp-review-outer-cont is never mistaken for nn-review-outer-cont — one letter apart, and two different generations of the plugin.

Where the markup genuinely cannot tell two endpoints apart — the modern Heatmap and the modern Service Area + Reviews combo render nearly identical HTML — it names both rather than picking one. A support tool that confidently names the wrong thing is worse than one that is honest about the ambiguity.

Built to be forwarded

Every run produces a plain-text summary with a Copy summary button. No markup, no class names, no internal endpoint names — written to be pasted straight into an email to the client or the web developer, and to survive Help Scout, Gmail, a ticket comment and somebody's phone without looking broken.

The summary is stored with the run, so what a client was sent and what the history shows stay the same text even after we change the generator.

Runs are kept per account, with the page, the result, the review and check-in counts, and who ran it. Agencies see the most recent run for a client on that client's detail page.

Now, the page views

Once you know the content is there, the question becomes how often it is served. That is what the Page View reports are for — and they have been rebuilt too.

Every time your website serves a Nearby Now city page, checkin, review block or gallery, we count it. That count has always been the honest answer to "is any of this being seen?"

It has also, for years, been the wrong number. Not wrong on purpose — wrong because it counted everything. A homeowner in Boerne on their phone, Googlebot indexing you at 3am, an uptime monitor, and increasingly, an AI assistant reading your pages to answer somebody's question about who fixes air conditioners nearby. All one figure, all labelled "page views."

Any agency that looks closely at a number like that discounts it on sight, and they are right to.

Three reports

Under Reports → Page Views:

• By Source — the headline impressions figure, split into desktop and mobile, with search crawlers and AI crawlers charted beside it on a stacked daily trend
• By City — how many people your content reached in each city you sell into
• Daily By City — the same thing day by day, for the month where something obviously changed and you want to know which day it changed on

All three export to CSV and to PDF. Dates are your own local dates, not a server's.

Impressions means people

The number at the top of every report is desktop and mobile visitors. Nothing else.

Search crawler traffic sits beside it in its own card. AI crawler traffic in its own. Anything we cannot confidently classify goes in a fourth card marked Other. None of the three is ever folded into the impressions figure.

This makes the headline number smaller. It also makes it a number you can put in front of a client without a caveat, which is the entire point.

AI crawlers get their own line

Search crawlers have been around forever and everybody knows to discount them. AI crawlers are different: they are the fastest-growing slice of automated traffic on the web, they are not indexing you for a results page, and folding them in with Googlebot hides something worth knowing.

We now identify them separately — GPTBot, ChatGPT-User and OAI-SearchBot, ClaudeBot, PerplexityBot, Google-Extended, Applebot-Extended, CCBot, Amazonbot, Bytespider, Meta's crawlers and a dozen more.

That line is not vanity traffic. When an AI assistant answers "who does emergency plumbing in Fair Oaks Ranch," it answers from pages it has read. Your city pages — real jobs, real neighbourhoods, real photos, real dated reviews — are exactly the kind of page that gets read.

And it is the second reason the health check matters. A page whose content only appears after JavaScript runs is invisible to AI crawlers for the same reason it is invisible to Google. You cannot be quoted from a page nobody can read.

One month at a time — and why last month

Every page view report now runs a calendar month and opens on the previous complete month. The picker goes back thirteen months. The current month is always labelled (to date), on screen and in the exported file name, so a part-month figure never gets filed next to a full one and mistaken for it.

The default is not an accident. Last complete month is the period the Monthly Scorecard reports, and a client holding the emailed scorecard in one hand and the on-screen report in the other must not see two different numbers for the same period.

The monthly bound is also what brought these reports back at all. They had been switched off — an open date range let a single request scan years of raw log rows, and that was not something we were willing to keep serving. Rebuilding the capture side as daily rollups, and putting the bound in the report itself rather than in a date picker somebody can edit around, fixed the thing that had them turned off in the first place.

What we do not keep

Traffic is classified at the moment the page is served, and only the classification is stored. The browser identification string itself is never kept. That was most of what the old logging table held, and nothing ever read it.

Where to find both

Plugin Health Check is under Advanced → Tools → Plugin Health Check, for account owners, agency administrators and super administrators.

Page View reports are under Reports → Page Views, or from the report catalog. Available on any account with Nearby Now content on its website — the WordPress plugin, the JavaScript widgets, or a direct API integration.

Run the health check on one city page first. If it passes, open By City for last month: the cities at the top are the ones your content is already winning, and the cities at the bottom, measured against the city page quality standard, are next month's work.

If it fails, you have just found something worth considerably more than a report.