Password fields never sit beside ads

The account screens on Oernoe are not publisher inventory. That sentence is short on purpose. It is also the rule that keeps login, signup, password reset, and the product apps outside AdSense. When people mash the network into one privacy story, they often skip the placement half of the story. Placement is where policy and product meet. Google’s publisher rules care about where units sit. Our own product rules care about the same surface for a different reason: a password field is not public writing, and a private message list is not a journal article.

This essay stays on that placement line. It does not walk through chrome. It does not invent a new monetization promise. It restates, in editorial language, what Using an Oernoe account already says under “What never shows ads,” and what Search queries and Google ads already says about where units are allowed. If those guides and this piece disagree someday, the guides win until we correct the record.

## Two systems, one operator, different surfaces

Anoepal operates a search engine and a publisher website. They share a company. They must not share an advertising file of your queries, and they must not share a habit of treating every hostname as inventory. Search lives at search.oernoe.com. The publisher lives at www.oernoe.com. Account login and signup live on the account host. Product work happens on the service hosts named on the homepage: Health, Chat, AI, Docs, Drive, Tracker, and Search itself. Ads are a publisher-page tool on selected finished documents. They are not a coating for every screen that happens to carry the logo.

That split is easy to blur in casual talk. It is harder to blur when you ask a concrete question: does this page need a password? Does this page show someone else’s private messages? Does this page exist only to authenticate or to open a product store? If the answer is yes, AdSense does not belong there. Using an account is blunt about it. Login, signup, password reset, and the product apps do not load AdSense. Putting ads next to a password field or a private message list would be both a policy problem and a product problem.

The policy problem is the one a reviewer already knows how to name. Units should not sit where they can be confused with navigation, downloads, or form controls. Units should not sit on thin shells or on pages a person cannot evaluate as documents. The product problem is simpler and more local. Signing in is a security moment. Resetting a password is a recovery moment. Opening Chat or Health is a private-data moment. Those moments are not improved by a third-party advertising script that exists to measure and serve commercial units on public writing.

## Public writing is the only ad surface we defend

Ads, when they exist, are on public writing: guides, How-To, and finished journal articles that still pass originality and length checks. That is the inventory map Search queries and Google ads publishes in plain language. The Cookie Policy and Privacy Policy say the same thing in legal register. Eligible pages may load AdSense. Home, About, Team, Contact, editorial standards, the guides index, legal pages, login, signup, password reset, the journal listing, error pages, and the apps themselves stay off that list.

Notice what that list protects. It protects the account form. It protects the reset form. It protects the product surfaces where your files, notes, messages, and prompts live. It does not pretend the whole network never touches advertising technology. Selected publisher pages on www may show Google ads. We will not claim the site never carries ads in the sense reviewers rightly reject. We will claim a narrower, checkable rule: password fields and private product lists do not sit beside those units.

The Using an account guide itself may show ads because it is public documentation on the publisher host. That is not a contradiction of the login rule. Documentation about accounts is still a finished public page. The account login screen is not. Confusing those two is how you get a false scandal or a false comfort. The honest check is the screen you are looking at, not the theme of the sentence you just read.

## Why a password field is a hard line

A password field is not decorative. It is the control that accepts a secret. Even when the page is otherwise ordinary HTML, the presence of that control changes what the page is for. The page is for authentication. Authentication is not a reading experience we are trying to fund with contextual units. It is a gate into stores that belong to the product you used: Drive files, Docs documents, Chat messages, Health notes, AI prompts. Those stores are not public journal articles, and they are not a source of advertising profiles for Search. Using an account says that directly. Ads next to the gate would teach the wrong lesson about what the gate is.

Password reset is the same category. Forgot Password is recovery, not publishing. The recovery message that arrives is not a commercial page either. If a verification message arrives after signup, Using an account says it is for recovering the inbox later, not a paywall. None of that flow becomes healthier if the form that starts it loads an advertising client meant for finished guides and journal pieces. Session lists and two-factor settings in account settings sit on the same side of the line: security surfaces, not publisher inventory.

## Private message lists and product apps

Chat is private messaging with account-level controls. Health is a private workspace for notes you choose to keep. Docs and Drive hold files and documents with sharing you can see. AI holds prompts you put into the product. None of those surfaces is the publisher site. Search queries and Google ads is explicit: we will not put ads on Chat, Drive, Docs, Health, or other private product surfaces. Those are not publisher pages.

A private message list is the clearest example for readers who do not want to memorize hostnames. Messages are not public writing. They are not How-To steps. They are not a finished journal essay with a word-count floor. An ad unit beside that list would sit next to other people’s words and your own, in a context where the next click is often reply, not read a guide. That is a product failure even before it is a policy failure. The same logic covers Health note lists, Drive folder views, and Docs editors. The homepage directory sends people to those hosts as products. The ads map keeps AdSense off them.

## Defect reporting is part of the promise

Rules that never describe failure modes are brochure rules. Using an account closes the loop: if an ad ever appears on the account login or sign-up screens, that is a defect. Screenshot it and send it to support@oernoe.com. Search queries and Google ads adds the same posture for units that look like navigation or download buttons. Report them. Do not treat a stray unit as a new policy.

When you write support, do not send the password. Using an account already tells people that for signup failures and for deletion requests. Browser, time, hostname, and a screenshot of the unit are useful. The secret in the field is not.

## What this essay is not claiming

This essay is not a walkthrough of the signup form. Step-by-step screens live on How-To. Using an account is the account itself: what it is for, what it is not, how to recover it, and why login never shows ads. We are staying in that register.

This essay is not a claim that www never shows ads. Eligible finished pages may. ads.txt names the publisher ID. Privacy and Cookies describe what Google may process when units load. Non-personalized requests are the default we ask for; that is not the same as no advertising data exists. We will not recycle the old homepage mistake that sounded like the whole network had no tracking while the publisher was applying for AdSense. About already named that correction. We keep naming the split instead of erasing it.

This essay is also not a claim that every www path without a password is fair game for units. Legal pages, Home, About, the journal listing, error pages, and thin stubs stay off inventory for their own reasons. The password-field rule is necessary, not sufficient. The broader eligibility map lives in Search queries and Google ads and in What we publish.

## How to check the line

Look at the hostname. Account screens belong on account.oernoe.com. Older www paths for login and signup may still resolve so old links do not break; hostnames guidance treats them as application shells with noindex and without ads. If you are signing in, you should be on the account host. If you are reading this journal piece, you should be on www. If an ad unit appears on Chat or Drive, that is a bug. If an ad unit appears beside the password field on login or signup, that is the same class of bug with a clearer screenshot.

## Why the rule stays boring on purpose

Boring placement rules are easier to keep than clever ones. Clever ones invite exceptions: a small unit under the fold, a sponsored link styled like a menu, a temporary unit on the reset page because conversion metrics looked soft. Oernoe’s recovery as a publisher already required deleting brochure habits—generic SEO stubs, coming-soon notes, and product names written as if they were live when the homepage did not list them. The account ads rule is part of that recovery. It refuses to monetize the moment you type a secret or open a private list.

Creation remains free. There is no credit card on the signup form. If a paid feature exists later, it has to be labeled as paid. That deal is about billing honesty. The ads deal is about surface honesty. Free signup does not mean monetize the form with AdSense instead. Labeled premium later does not mean ads on Chat until a premium toggle ships. Optional premium and publisher ads are separate funding tools. Password fields stay outside AdSense, and premium labeling belongs in the product, not in a fake unit beside the password.

## Closing

If you arrived here from an ads review, start with Search queries and Google ads, then Using an account, then this piece as editorial reinforcement—not as a substitute for view-source. If you arrived here because a password form looked wrong, screenshot and write support@oernoe.com. If you wanted a privacy slogan without placement detail, you will be disappointed on purpose. Placement detail is the part that survives contact with a live page.

Password fields never sit beside ads. Private message lists never sit beside ads. Product apps do not load AdSense. Public writing on selected finished www pages may. Those four sentences are enough to run the company without mashing the systems back into one false story. We will keep them aligned with the guides, and we will treat any login or signup unit as a defect until the screen matches the rule again.