OAuth branding verification: both findings are factually incorrect on the live homepage (PII Removed by Staff)

Project ID: (PII Removed by Staff)
App name: Broadcast Your Gems
Homepage: (URL Removed by Staff)
Publishing status: In production, External
Scope involved: https://www.googleapis.com/auth/youtube.readonly (sensitive)

Hello,

My brand verification keeps failing with two findings that are, as far as I can
verify, factually incorrect for my live homepage. I would appreciate a manual
look at the project.

THE TWO FINDINGS

  1. “Your home page does not explain the purpose of your app.”
  2. “The app name ‘Broadcast Your Gems’ configured on the OAuth consent screen
    does not match the app name indicated on your home page.”

WHY I BELIEVE BOTH ARE INCORRECT

My app is a free public platform where an Italian community discovers small
YouTube channels (under 7,000 subscribers) and votes the best ones into a public
feed. Creators can claim their own channel, which is what youtube.readonly is
used for.

Checked against the raw HTML of (URL Removed by Staff) (no JavaScript
execution, requested with a Googlebot user agent):

  • The page returns HTTP 200 and is fully server-side rendered. It is public and
    requires no login of any kind.

  • is exactly "Broadcast Your Gems". The og:title meta tag is exactly "Broadcast Your Gems". The same string is visible text in the header and in the footer of every page. This is character-for-character identical to the App name configured on the OAuth consent screen, which makes finding 2 hard for me to reproduce.
  • The first screen of content states what the app does, and the same sentence is
    in the meta description.

  • The homepage contains a dedicated section explaining why the app requests
    Google user data, naming the scope explicitly: youtube.readonly is used only
    to read the list of channel IDs the signed-in user owns, so we can verify that
    a creator claiming a channel really owns it. We never publish, modify or
    delete anything on their channel.

  • Links to the privacy policy (/privacy) and terms of service (/termini) are in
    the footer of every page. Both return HTTP 200 publicly.

  • robots.txt contains no Disallow rules.

  • The domain is a verified property in Google Search Console, owned by the same
    Google account that owns this Cloud project.

WHAT I HAVE ALREADY TRIED

  • Removed a root-level loading.tsx (Next.js App Router) that used to make the
    homepage render as an empty loading skeleton for clients without JavaScript.
    Since that fix the full content is in the initial HTML response. I verified
    this with curl, not just in a browser.
  • Made the footer brand read the full name “Broadcast Your Gems” instead of an
    abbreviation, to remove any ambiguity about the app name.
  • Clicked “I have fixed the issues” several times. The same two findings come
    back unchanged every time.

WHAT I AM ASKING FOR

Could someone from the team look at (PII Removed by Staff) and tell me what
the automated check is actually seeing on my homepage? If the findings are
correct and I am misreading my own site, I am happy to fix whatever is wrong,
but I cannot act on findings I am unable to reproduce.

Thank you.

Your note about the root loading.tsx stood out to me. That kind of initial-HTML vs hydrated-page difference can make an automated homepage check see something different from what you see in the browser.

I built a small free preflight focused on the public website side of Google OAuth verification:
(URL Removed by Staff)

It fetches the initial homepage HTML without executing JavaScript and checks app-name signals, policy links, origin consistency, and the OAuth scopes you enter.

It doesn’t inspect your Google Cloud Console or trigger a re-review, but it may help confirm whether the current public homepage still exposes anything that could explain those two findings.