Link to Login Page

Element Code: LI-034

What this check flags

This check fires when a meaningful share of your internal links point at a login page or at URLs that bounce unauthenticated visitors to one: /login, /wp-login.php, /account/signin?redirect_to=..., members-only articles, customer portals, gated dashboards. A crawler follows the link, hits an authentication wall, and the road ends. Googlebot does not have your password and will never fill in the form.

One "Log in" link in the header is normal and harmless. The check exists for the pattern beyond that: hundreds of content links funneling into gated destinations, or a login URL that mutates into thousands of parameterized variants because every protected page generates its own ?redirect_to= address.

Why this matters

Three separate problems hide under this one flag, and they have different price tags.

Crawl budget bleed. The redirect parameter is the sneaky one. If /premium/article-123 redirects to /login?redirect_to=%2Fpremium%2Farticle-123, then every gated URL manufactures a unique login URL. Crawl a site with 20,000 protected pages and you have handed Googlebot 20,000 worthless variants of the same form. I have seen log files where a double digit percentage of Googlebot hits went to login variants while new product pages waited days to be discovered. That is a genuinely stupid way to spend your crawl budget.

Invisible content. Whatever sits behind the wall does not exist to search engines unless you deliberately expose it. If your best material is members-only and you link to it heavily, you are voting PageRank into pages that can never rank, while the crawler sees your "most important" links dead-ending.

Wrong page ranking. When enough internal links concentrate on /login, that page accumulates authority and starts showing up in the SERPs for brand queries, sometimes above the pages you would rather a new visitor land on. A bare login form is a lousy front door for a first impression.

How to detect it

Crawl the site with Screaming Frog and sort by inlink count: a login URL sitting in your top 20 most-linked pages is the tell. Then filter the crawl for URLs containing login, signin, auth, or a redirect_to style parameter and count the unique variants; more than a handful means the parameter is spawning duplicates. Cross-check server logs for how often Googlebot actually requests those URLs, and search site:yourdomain.com inurl:login to see whether any variants made it into the index. In Search Console, the Pages report will often show them under "Crawled, currently not indexed" or "Page with redirect," which is Google politely telling you it keeps visiting a door it can never open.

How to fix it, step by step

1. Inventory every URL pattern involved: the login page itself, its parameter variants, and each gated section that redirects there. The Screaming Frog inlinks export gives you the linking templates in one pass.

2. Disallow the login path in robots.txt (Disallow: /login, plus /wp-login.php on WordPress). This stops the crawl waste immediately, including all parameter variants. Add a noindex header or meta on the page for the variants already indexed, and remember a page must be crawlable for noindex to be seen, so apply noindex first if cleanup matters, robots block second.

3. Decide, per gated section, what you want from search. If the content should rank: expose a preview (headline, lead paragraphs, key takeaways) to everyone, keep the rest behind the wall, and add isAccessibleForFree: false with a hasPart block in your Article schema so Google understands this is a legitimate paywall rather than cloaking. If it should not rank: stop linking it from public templates entirely and let it live behind the single disallowed gateway.

4. Strip or canonicalize the redirect parameter so all login variants resolve to one clean /login URL server side.

5. Recrawl and re-check logs after two weeks. Success is boring: Googlebot's login requests drop to near zero and the reclaimed budget shows up as faster discovery of new pages.

What good looks like

The login page carries exactly the links users need, sits behind a robots.txt disallow, and never appears in the index. Gated content either shows a marked-up preview that ranks and converts, or stays fully private by design instead of by accident. Your log files show Googlebot spending its visits on content, and this check returns a handful of intentional utility links instead of a four-digit count.

FAQ