Brand verification: the consent screen shows our domain, not the configured app name — is that the string compared against the home page?

Google Cloud Cloud Foundations & Onboarding
1

What we see:

Our OAuth consent screen does not display the app name we configured. Under “Developer information” it shows:

Continue to willowyrd.com

App name:      willowyrd.com
Support email: (our support address)

The app name configured in the console is Pairwave, and Google’s own rejection text quotes it as such: “The app name ‘Pairwave’ configured for your OAuth consent screen…”. But what the screen displays is the registrable domain from Authorized domains: willowyrd.com.

Brand verification has now rejected us four times. After the last review only one finding remains:

The app name shown on your OAuth consent screen does not match the app name on your home page.

Read literally, against what the screen actually shows, that finding is true: willowyrd.com is not Pairwave. Our home page at https://pairwave.willowyrd.com says Pairwave in its single <title>, its single <h1>, application-name, og:title, og:site_name, twitter:title, the web app manifest (name and short_name) and the schema.org JSON-LD.

Note that pairwave.willowyrd.com cannot be entered in Authorized domains at all — that field only accepts the registrable domain — so a subdomain can never be what is displayed.

Why this may not be specific to us

An unverified app cannot display its configured name; the domain is shown instead. If the check compares that displayed string with the brand name on the home page, the two can never match. Other reports on this forum fit the same shape.

What we verified on our side

Our reverse proxy logs show the verification fetcher retrieving the correct page. For the most recent attempt:

[06/Aug/2026:00:37:33 +0000] 200 GET "/"        [Client 66.249.83.130] [Length 13083] "Google"
[06/Aug/2026:00:37:33 +0000] 200 GET "/privacy" [Client 66.249.83.130] [Length 8863] "Google"

Both HTTP 200, no redirects, in the same second, for exactly the two URLs configured on the consent screen. 13,083 bytes is the complete current home page, gzip-encoded. The same client then issued 21 client-side router prefetches, so the page was rendered, not only downloaded. The address forward-confirms to google-proxy-66-249-83-130.google.com. The rejection arrived minutes after this fetch, so it was not decided on a stale copy.

Questions

  1. Does the branding check compare the displayed app name — which for an unverified app is the domain — against the name on the home page? If so, how is any unverified app expected to pass?
  2. If not, which string was extracted as “the app name on your home page”, and which URL was treated as our home page?
  3. Is there a supported way to have the configured app name displayed before verification completes?

Status

Appeal filed on 2026-08-06 (“I believe the issues found are incorrect”). The Verification Center tells us to reply to the Trust & Safety email thread, but no such email has ever arrived — which several of the threads above also report.

Additional evidence: the displayed string is not the App name field

Since posting we have been able to isolate this with a single variable. We use
one OAuth client for both local development and production — same project,
same client_id, same consent screen configuration, nothing toggled between the
two. The only difference is the redirect URI the request comes from:

  • http://127.0.0.1:3000/api/auth/callback/google → the consent screen shows
    Pairwave, the configured App name.
  • https://pairwave.willowyrd.com/api/auth/callback/google → the same client,
    checked back to back, shows willowyrd.com

If the consent screen rendered the App name field, both would read “Pairwave”.
They do not. The displayed string is derived from the entry in Authorized
domains that matches the redirect URI, and the configured name appears only
where no such entry can exist — 127.0.0.1 cannot be added to Authorized
domains, since that field rejects localhost addresses.

Two consequences for the one remaining finding:

  1. The “app name shown on your OAuth consent screen” is not a string we can set.
    For an unverified app it is the registrable domain, so it can never match a
    brand name on a home page — for us or for anyone else in this position.
  2. It is not even the domain of the page that was reviewed. Authorized domains
    accepts only the registrable domain, so the screen shows willowyrd.com,
    while the home page the fetcher retrieved — and that the finding compares
    against — is pairwave.willowyrd.com.

So the only two ways to clear the finding as literally written are to rename the
app to willowyrd.com, contradicting the App name field, our home page and our
actual brand, or to have branding verified first — which is what this finding
blocks.

2

Hello, after a few days google mailed me about this and it got solved, now i’m correctly in the verification process.