Application (non-public) part of the site

Whether this page looks like an application (non-public) part of the site - login, cart, account, admin - rather than content you manage. Decided by one of four signals, in this order of strength:

• A password form (<input type="password">) - decides on its own.
• An unambiguous address (/login/, /cart/, /wp-admin/…) - also on its own.
• A portal/account address (/dashboard/, /account/…, which can also be a public product page), but only when backed by a FURTHER signal: the site demonstrably has a login elsewhere, OR this page itself carries noindex.
• A typical heading or title ("Log in", "Cart", "My account"…), with the same condition as above - never on its own.

When the check flags a page this way, it merges content checks into this single finding that would otherwise produce a separate finding for EACH such page: a missing title, meta description, headings, images without alt text, or structured data (STR-01…08, SCH-01, SCH-03…06, and SEO-39 in the SEO module). The report shows "N pages" for such a code instead of individual cards.

What the check does not do:

• Does not click, log in, or see content behind a login. It judges only the publicly available HTML of that page, the same as the rest of the audit.
• Does not merge access checks, robots.txt or technical checks (error status, canonical, redirects) - those stay separate on an application page, because an application page with a 500 error is still an error.
• Does not decide whether the page should be public. It only describes that it looks like an application part, leaving the decision to you.
• Does not claim certainty about the classification. It is a heuristic over four signals, not a certainty - which is why the finding is informational, not a defect.

This is not a recommendation, so there is nothing to document an AI effect for. The finding promises nothing and has no effect on visibility in search or in AI answers in either direction - it is information about how the audit classified the page, not about how it performs with search engines.

What IS documented is the reason this check exists. An external review of the product and our own dogfooding showed that a publicly reachable portal without a login (typically /login, /cart, /account/*, /wp-admin) added a separate finding about a missing title/description/heading for EVERY such page - the customer experienced it as noise and had no way to fix it, because the content is managed by the application, not by them.

That is why the heuristic combines several signals rather than one. An address decides on its own only where it is unambiguous (login, cart); for an ambiguous address (/dashboard/ can also be a public product page) it requires a second, independent piece of evidence - noindex, or that the site demonstrably has a login elsewhere.

First check whether the classification is right. Open the page in a private/incognito browser window (without logging in) and look at what you actually see.

If the classification is right and the page is meant to stay non-public, there is nothing to do - it is an informational finding and does not affect your score.

If the page is meant to be public and the classification is a mistake, remove the login requirement or the noindex tag and run the audit again - the content checks will then apply here too, like on any other page.