App name: LTCLevTec Ads Platform
Project ID: ltclevtec-ads-platform (project number: [PII Removed by Staff])
Application home page: (URL Removed by Staff)
Scopes: https://www.googleapis.com/auth/adwords only (not sensitive or restricted; the Data access status card confirms verification is not required for our scopes)
Status: External, In production
I am stuck in the automated brand verification loop. Every attempt returns the same two findings:
- “Your home page does not explain the purpose of your app.”
- “The app name LTCLevTec Ads Platform configured for your OAuth consent screen does not match the app name on your home page.”
What I have already done:
- Created a dedicated app page (the Application home page URL above). Its H1 is exactly “LTCLevTec Ads Platform”, character for character matching the consent screen app name. The page describes the app’s purpose in plain static HTML: a managed Google Ads service for small business clients, with an explicit statement that the app uses the Google Ads API solely to manage campaigns and retrieve spend and performance reports for client accounts under our manager account.
- Updated the Application home page field on the consent screen to point to that page and saved before resubmitting.
- The page links to our privacy policy at /privacy.html (same URL configured on the consent screen) and terms at /terms.html, is on our authorized domain, and requires no login.
- The domain is verified in Google Search Console under the same account.
- Ran a live URL test in Search Console on the app page: result “URL is available to Google”, page fetched and rendered successfully, so it is not blocked by our CDN.
- Resubmitted with “I have fixed the issues” multiple times; identical automated findings each time, no Trust and Safety email received.
This appears to be the same automated checker loop reported in several recent threads with this tag. Could someone take a manual look at the verification for this project? Happy to provide anything else needed. Thank you.
I am also facing the same issue
Project ID: (PII Removed by Staff)
App name: RevRoot
Hello,
Brand verification for this project has returned one finding:
“The app name shown on your OAuth consent screen does not match the app
name on your homepage.”
I believe this is inaccurate against the current homepage, and I would be
grateful if the team could re-crawl the live page rather than rely on an
earlier cached capture.
Evidence — all verifiable right now
The OAuth consent screen App name is exactly “RevRoot”: seven characters, no
leading or trailing whitespace, no unusual characters.
“RevRoot” appears 59 times in the server-rendered HTML of the homepage,
including the navigation wordmark, the H1 (“RevRoot is the social commerce OS
for ecommerce.”), the page , and the footer.
Every machine-readable name declaration reads exactly “RevRoot”:
-
-
-
manifest.webmanifest: “name”: “RevRoot”, “short_name”: “RevRoot”
-
schema.org JSON-LD: Organization, WebSite and SoftwareApplication, each
with “name”: “RevRoot”
-
the Open Graph image is a full-bleed “RevRoot” wordmark
No other product or company name appears anywhere on the page.
Why earlier reviews may have seen something different
An earlier review also reported that the homepage did not explain the purpose
of the app. Investigating that, we found a scroll-triggered animation left all
content below the fold at opacity:0 for any renderer that did not scroll. A
full-page capture measured 1512x10036 pixels, of which roughly 90% rendered as
empty background — an automated capture taken without scrolling would have seen
only the hero section.
That defect was fixed and deployed on 2026-08-05, and the homepage-purpose
finding cleared on the next review. So the page is being read correctly now,
and I would ask that the app-name check be re-run against a fresh crawl rather
than a capture taken while that defect was live.
Grisha Gabrielyan
RevRoot — (PII Removed by Staff)
One thing I’ve noticed with small service businesses is that the website itself can become part of the verification problem. It’s easy to focus on getting the OAuth settings, domain verification, privacy policy, and consent screen configured correctly, while overlooking whether the homepage actually makes the business purpose obvious to someone seeing it for the first time.
A simple test I like is to have someone unfamiliar with the business open the homepage and explain, in their own words, what the company does, who it serves, and what action they can take next. If that isn’t immediately clear, an automated reviewer may struggle with it too.
This seems especially important for smaller businesses where the website may be the main place a potential customer learns about the service. Keeping the business description, service information, contact details, and supporting pages consistent across the site can make the whole online presence much easier to understand.
I’d be interested to know whether Google’s checker is actually evaluating the rendered page content or relying more heavily on specific metadata/branding fields, because that distinction would explain why a dedicated compliant page can still get stuck in this loop.