Brand verification: name-mismatch flag persists though consent screen and homepage match — no Trust & Safety email received

Google Cloud Cloud Foundations & Onboarding
1

Requesting a re-review. I have the same symptom others have reported here:
a brand-mismatch flag that persists after the mismatch was fixed, with no
Trust & Safety email ever arriving (checked inbox, spam, and archive with
in:anywhere — nothing).

Project number: (PII Removed by Staff)
Project ID: (PII Removed by Staff)
Consent screen app name: AILIST
Registered homepage: (URL Removed by Staff)
Scopes: userinfo.email, userinfo.profile, openid (no sensitive/restricted)

-– Original flags —

  1. “The homepage does not contain a description of the app’s purpose.”
  2. “The app name configured on the OAuth consent screen does not match the
    app name on the homepage.”

-– What I fixed, and when —

  • 2026-07-28: unified the app name across the site. The meta tags
    application-name and apple-mobile-web-app-title were “AiList” while the
    consent screen was “AILIST”; both are now “AILIST”, and og:site_name was
    added.
  • 2026-07-29: replaced the registered homepage with a dedicated description
    page, (URL Removed by Staff) , which states the service purpose in
    server-rendered HTML and links to /privacy and /terms.

-– Current state (verifiable with curl, no JavaScript required) —

AILIST 소개 ("AILIST Introduction")

AILIST

HTTP 200, 0 redirects, publicly accessible, no login wall Links to /privacy and /terms present The only occurrences of the string "TheAiList" are inside an inline script (a user-agent token for app-mode detection) and are not rendered text. Domain theailist.io is verified in Search Console as a Domain property under the project owner account.

-– Why I am posting here —
Across several submissions the same two findings were returned even after the
above was in place. Across several submissions the same two findings were returned even after the
above was in place. To be precise: on the most recent submission I changed
nothing in the consent screen configuration either before or after clicking
resubmit, and the identical two findings were returned regardless. I have
filed an appeal (“the finding is incorrect”) for both items.. I have filed
an appeal (“the finding is incorrect”) for both items.

Could someone trigger a re-review, or tell me where a reply is expected when
no Trust & Safety email thread exists?

2

Getting similar issue

Title: OAuth branding verification stuck on “purpose not explained” + “name mismatch” despite homepage being compliant — [project_name]

Project name: [project_name]
Homepage: [project_name]
Verification type: Branding / Homepage requirements
Project ID / Project Number: happy to share privately with an authorized Google staff member

Issues returned by the Verification Center (unchanged across multiple resubmissions):

  1. “Your homepage does not explain the purpose of your app. Update your homepage to outline the purpose of your application.”
  2. “The app name [app_name] configured for your OAuth consent screen does not match the app name on your homepage.”

Why I believe the homepage already satisfies both requirements:

  • App name “ELMA AI” appears as real, server-rendered text in:

    • ELMA AI Receptionist | 24/7 AI Phone Answering & Appointment Booking

    • The homepage : “ELMA AI - Build Your AI Receptionist. Go Live in Minutes.”
      This exactly matches the app name configured on the OAuth consent screen (“ELMA AI”).

  • The homepage explains the app’s purpose in plain, server-rendered HTML (confirmed via plain curl, no JS execution required):

    • Meta description: “ELMA is a SaaS platform to create your own AI receptionist. Answer business calls, website chat, and voice widget conversations 24/7, book on Google Calendar & Outlook, and go live in minutes.”
    • Hero section body copy explaining the product directly below the H1.
    • A dedicated FAQ item “What is ELMA?” with a full description of the app.

  • Confirmed via curl with a Googlebot user agent that the page returns HTTP 200 with all of the above content present in the raw HTML (no JavaScript required, no redirect, no bot-challenge page).

  • robots.txt allows all user agents on /.

  • Site is not behind Cloudflare or any bot-challenge proxy (direct Apache origin, verified via response headers).

  • Privacy Policy ( Privacy Policy | ELMA AI ) and Terms ( Terms of Service | ELMA AI ) both return 200 and match the URLs configured on the consent screen.

  • Domain ownership for the parent domain Focusteck is verified in Search Console.

Despite the above, resubmitting for verification returns the identical two flags every time, with no email from a Trust & Safety thread to reply to.

Could someone from the Google Cloud team manually re-check this homepage or advance the review? Happy to provide the Project ID/Project Number privately, along with a timestamped screen recording of the raw page source if useful.

Thank you.

3

Thanks for adding your case — this is useful because our stacks have nothing
in common.

Ours: Next.js on Vercel behind Cloudflare, Korean-language site.
Yours: direct Apache origin, no proxy, English site.

Yet the two returned findings are word-for-word identical, and neither
changes no matter what we fix.

Additional checks on our side, all passing:

  • The registered homepage returns HTTP 200 with 0 redirects and the complete
    server-rendered body for every user agent tested — empty UA, curl,
    python-requests, Googlebot, Google-InspectionTool, GoogleOther and
    Google-Safety. Identical byte size in all cases, no bot challenge.

  • robots.txt: “User-agent: * / Allow: /”

  • and

    both contain the exact consent-screen app name

  • Purpose description present in raw HTML with no JS required

  • Privacy Policy and Terms linked, both returning 200

  • Domain verified in Search Console as a Domain property

  • Non-sensitive scopes only

Two unrelated sites, two different hosting stacks, one identical verdict that
does not respond to any change. That points at the checker not reading the
current page.

4

I am experiencing the same problem with a separate application and hosting stack.

Application details

  • OAuth consent-screen app name: Demand Orbit
  • Requested scopes: openid, userinfo.email, userinfo.profile, youtube.readonly, yt-analytics.readonly, and youtube.force-ssl

Demand Orbit is a YouTube channel intelligence and publishing platform for channel owners and their authorized representatives.

The application uses read-only YouTube and Analytics access to identify an authorized channel and prepare channel intelligence reports. The publishing scope is used only when an authorized user explicitly chooses to publish or update a YouTube video and its associated metadata.

Repeated findings

The Verification Center repeatedly reports:

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

We have corrected and independently verified every applicable requirement:

  • The registered homepage is publicly accessible.
  • It returns HTTP 200 without redirecting.
  • The HTML title is exactly <title>Demand Orbit</title>.
  • The page contains a visible <h1>Demand Orbit</h1>.
  • The application name appears in the raw, server-rendered HTML.
  • The page visibly and explicitly explains the application’s purpose.
  • It explains how authorized Google and YouTube data is used.
  • Privacy Policy and Terms of Service links are clearly visible.
  • The application-name, og:title, and og:site_name metadata all match Demand Orbit exactly.
  • The displayed branding matches the OAuth consent screen.
  • There is no login wall or bot challenge.
  • robots.txt permits ordinary search crawling.

We tested the registered homepage using the following user agents:

  • Googlebot
  • Google-InspectionTool
  • GoogleOther
  • Google-Safety

Every user agent received the same complete HTML response containing the exact application name and purpose statement.

No Trust & Safety email

We have triggered re-verification multiple times after correcting the reported issues, but the same two findings continue to return.

We have also never received an email from Google Trust & Safety. We checked Inbox, Spam, Trash, All Mail, every configured support and developer-contact address, and the project-owner accounts.

There is no Trust & Safety email thread to which we can reply.

Assistance requested

Could someone from Google please:

  1. Manually refresh or rerun the homepage and branding assessment?
  2. Confirm which homepage snapshot and application-name values are being compared?
  3. Identify the specific mismatch still being detected?
  4. Resend or establish the missing Trust & Safety email thread?
  5. Escalate the application for manual review if the automated findings are stale?

We can provide the project number, project ID, OAuth client ID, test credentials, demo video, screenshots, raw HTML, response headers, and verification timestamps privately to an authorized Google representative.

UPDATE: I just heard from Google and they set everything straight. I didnt do anything more but post once in here and then just waited. Thank you Google for getting back to me.

5

I am having the exact same issue all three of you described, seems like a common issue.

Project Info:
ID: (PII Removed by Staff)

Project #: (PII Removed by Staff)

Consent screen name: KOIN MMA

Kept getting the following issues no matter what:

  1. The app name shown on your OAuth consent screen does not match the app name on your homepage.

  2. The homepage does not contain a description of the app’s purpose.

  3. Your logo does not uniquely identify your brand and identity.

So I pressed the appeal button (“finding is incorrect”) just like you guys did and it instantly rejected my appeal and said to respond to the email thread with the Trust and Support team but no such thread was ever created. Now in a deadlock

I am certain that these errors are being caused by the automated review workflow saving a stale copy of my html and thus not seeing that the initial errors were fixed.

As for the logo I’m not sure what criteria was violated since it is an entirely unique logo that I created myself.

Could anyone from Google let me know if I truly am still violating some criteria or retrigger the verification and see if it passes now? I would also greatly appreciate an explanation of why I got the logo error when it seems that’s not an error most people get?

Would love to know if you guys had your issues resolved and if so is there anything you did manually to get unstuck?

Thanks!

6

Same here — and your appeal experience matches mine.

I filed the appeal with “the finding is incorrect” for both items and was
told the same thing: respond to the Trust & Safety email thread. No such
thread has ever existed for my project. Inbox, spam and archive all searched
with in:anywhere — nothing.

So that makes four of us in this thread with:

  • the same two (or three) findings
  • findings that do not change no matter what is fixed
  • no Trust & Safety email thread to reply to
  • the appeal path pointing back at that non-existent thread

Our stacks have nothing in common:

  • mine: Next.js on Vercel behind Cloudflare, Korean-language site
  • ELMA AI: direct Apache origin, no proxy, English site
  • yours: separate project entirely

On my side every checkable requirement passes. The registered homepage
returns HTTP 200 with 0 redirects and the complete server-rendered body for
every user agent tested — empty UA, curl, python-requests, Googlebot,
Google-InspectionTool, GoogleOther, Google-Safety — identical byte size in
all cases, no bot challenge. robots.txt allows all. and both
contain the exact consent-screen app name. The purpose description is in the
raw HTML with no JS required. Privacy Policy and Terms are linked and return
200. The domain is verified in Search Console as a Domain property under the
project owner account. Scopes are non-sensitive only.

Nothing resolved on my side yet, and I have not found any manual action that
unsticks it. Your stale-HTML theory matches what I see: the verdict text is
byte-identical across submissions, including submissions where I changed
nothing at all between clicking resubmit.

Requesting a Google staff response for all four projects in this thread.

7

Hello,

I am experiencing the same issue with my OAuth app, FMM CLASSICO.

The Verification Center reported that the app name shown on the OAuth consent screen did not match the app name on the homepage. I have corrected the public website branding so that the official FMM CLASSICO logo and exact app name are clearly displayed on the homepage.

The Privacy Policy and Terms of Service are also publicly accessible, and the OAuth consent-screen app name is configured as FMM CLASSICO.

After resolving the issues, the Verification Center instructed me to reply to the Trust & Safety email thread. However, I did not receive any Trust & Safety email. I checked Inbox, Spam, Trash, Promotions, and All Mail, and the developer contact email configured in the project is correct.

Could a Google staff member please advise how I can continue the verification process or request that the Trust & Safety email be resent?

Project ID: (PII Removed by Staff)
OAuth app name: FMM CLASSICO

Thank you.

8

Resolved. My brand verification was approved.

What I did:

  1. Fixed a real mismatch I had missed — the meta tags application-name and
    apple-mobile-web-app-title still contained an old casing variant of the app
    name while , and the consent screen used the current one. I
    unified all of them and added og:site_name.
  2. Registered a dedicated description page as the homepage URL instead of the
    site root, so the purpose of the app is the first thing on the page.
  3. Filed an appeal (“the finding is incorrect”) for both items.
  4. Posted here.

Approval arrived after posting in this forum, not through the appeal or an
email thread — no Trust & Safety thread was ever created for my project.

So for anyone stuck: check your meta tags for name variants even if
and look correct, then post here with your project number, the exact
flags, and what you fixed. That combination is what unstuck it for me.

Good luck to the rest of you still waiting.

9

I’m seeing a similar issue. The consent screen and homepage branding appear to match, but the name-mismatch flag is still being triggered. I also haven’t received any email from the Trust & Safety team explaining the issue or requesting additional information. Has anyone else encountered this, and if so, how was it resolved? It would be helpful to know whether this is a review delay, a false positive, or something specific that needs to be corrected.