The trust signals that matter most to ad reviewers are the ones they can verify mechanically: valid SSL with history, working policy and contact pages with real entity details, a domain with clean reputation, and content that matches the target geo. Design polish and badge graphics carry almost no weight.
I've watched buyers spend real money on trust badges — padlock graphics, "verified" seals, stock photos of handshakes — while their contact page 404'd and their SSL cert was three hours old. The badges did nothing. The 404 probably cost them the review.
This article is the weighting: which signals reviewers and ad networks actually check, how each one gets verified, and which ones are decoration. If you want the full pre-launch checklist, that's a separate article: how to check a white page before a campaign. This one is about what carries weight.
What a reviewer actually sees
Exact moderation pipelines aren't public, but the shape is consistent across major networks: an automated pass first, then a human pass for flagged or sampled ads.
The automated pass fetches your URL the way any crawler would. Domain registration data. DNS. SSL. The redirect chain. Then it renders the page and reads what's there: text, links, scripts, policy pages. In most networks this pass also pulls reputation data — blacklist status, Safe Browsing — because that's cheap to query and mechanical to score.
The human pass, when it happens, is not a person admiring your design. It's a person with a policy checklist and a queue. Typically they see the ad next to the landing, the domain's basic data, and the rendered page — often at more than one viewport. They click the footer links. They check whether the claims in the ad match the claims on the page. They have seconds to minutes per review.
Everything below is weighted by one question: how fast can the reviewer verify it? Mechanical signals get checked every time because they cost nothing. Content signals get checked when something looks off. Visual polish gets noticed, but it isn't on the checklist.
Infrastructure signals: the mechanical layer
These are pass/fail, verifiable in seconds, and they carry outsized weight for exactly that reason.
SSL with a sane history. No valid certificate is an instant mechanical fail. A cert issued the same morning as the campaign isn't a fail, but it's a tell. Same-day cert plus week-old domain plus fresh hosting is a combination that reads as throwaway infrastructure even when the intent is honest.
Domain age and history. A brand-new domain has no track record, and reviewers treat "no history" as a risk factor, not a neutral one. A domain with a bad history — previously parked on scam content, dropped, re-registered — is worse. That history doesn't wash off.
Reputation. If your domain or its IP is already listed on DNS blacklists, Safe Browsing, or flagged by scanner engines, the review starts with a strike — sometimes the review never really starts. This is its own topic; I wrote a separate reference on domain reputation for media buyers. The short version: check it before the campaign, not after the rejection.
Redirects and email records. A redirect chain that hops through unrelated domains looks like evasion infrastructure even when it's sloppy setup. And if the domain sends mail — order confirmations, lead follow-up — missing SPF, DKIM, or DMARC records are absence where a real business has presence.
Content signals: the pages reviewers actually click
Trust pages that survive a click. Privacy policy, terms, contact. Reviewers follow these links — it's one of the most consistent parts of the job across networks. Three failure modes, in order of how often I've seen them: the link 404s; the page is a lorem-ipsum template; the page exists but names no real entity. A privacy policy that names a company, an address, and a working contact is a strong signal. One that could belong to any site on earth is a negative one.
A contact path that works. Test your own form. A dead contact form on a page that collects leads is the kind of detail that turns a marginal review into a rejection.
Language and geo match. An English page behind a .de domain, targeting a German offer, is a mismatch a reviewer catches in seconds. The page's language, the domain's TLD, the offer's geo, and the business details on the policy pages should all tell the same story.
Claim consistency. In most networks, the reviewer compares what the ad promises against what the page says. An ad that implies one thing and a page that says another is a policy problem, not a copy problem.
Content depth. Two paragraphs and a stock photo reads as a placeholder, because it usually is. You don't need a magazine. You need a page that could plausibly belong to a real business serving real customers.
Behavior signals: what the page does during the visit
This is the layer buyers think about least and detectors care about most.
Popups and forced interactions. A popup that blocks content on load, scroll-hijack scripts, a page that redirects when the visitor tries to leave — each is a small mark against the page. Countdown timers that reset on every reload are worse: in most networks that's a deceptive-practices flag, not a design choice.
Different content for different visitors. If the page serves one thing to a crawler and another to a user — by IP, by referrer, by user agent — that's a cloaking signal, regardless of intent. Legitimate setups trip this constantly: geo redirects, A/B tools, bot-protection challenges. How detection works and how to audit your own page for false positives is its own article: audit your own page before reviewers do.
Mobile behavior. Reviewers typically see the page at a mobile viewport too, and a page that's fine at 1440px and broken at 375px fails the visit the same way it fails the user. Popups that cover the phone screen, layouts that collapse below the fold — all of it is visible in a screenshot, and screenshots are part of modern review tooling.
The weighting table
| Signal | How it's verified | Weight in review | If it's broken |
|---|---|---|---|
| Valid SSL, sane cert age | Automatic | Pass/fail | Instant mechanical fail |
| Domain reputation (blacklists, Safe Browsing, VirusTotal) | Automatic | Pass/fail | Rejection risk before human review |
| Domain age and history | Automatic | High when bad | New domain + sloppy everything else fails |
| Working privacy/terms/contact | Human click-through | High | Among the most common rejection reasons |
| Real entity details on policy pages | Human | High | Reads as throwaway setup |
| Language/geo match | Human | Medium-high | Obvious in seconds |
| Ad-to-page claim consistency | Human | Medium-high | Policy flag, not copy note |
| Page behavior (popups, redirects, scroll) | Both | Medium-high | Deceptive-practices or cloaking suspicion |
| Content depth | Human | Medium | Reads as placeholder |
| Design polish, badges, seals | Human | Low | Decoration |
| Testimonials and review widgets | Human | Low — negative if fake | Fake proof is a policy problem |
The pattern in that table: anything you can buy as a plugin in five minutes carries no weight. Anything that takes real work — real policy pages, real entity details, a real contact path — carries weight precisely because it's hard to fake.
So the decoration list, because buyers over-invest here:
- Badge graphics. "SSL secured" icons, "verified" seals as images. Nobody on the review side clicks them.
- Stock-photo trust. Handshakes, headsets, smiling support teams. Neutral at best.
- Testimonial widgets with no verifiable source. Ignored when generic, harmful when obviously fabricated — fake reviews are a policy violation in most networks, not a trust signal.
- Fake urgency. Hard-coded countdowns that restart on every visit. Not a trust signal at all; a documented deceptive pattern.
FAQ
Is there a minimum number of trust signals a page needs?
No fixed threshold exists, and anyone selling one is guessing. The mechanical signals — SSL, reputation, redirects — are effectively pass/fail. The content signals are judgment calls a human makes in under a minute. Pass every mechanical check and give the human nothing to frown at: that's the whole game.
Do new domains fail review automatically?
No. Newness is a risk factor you compensate for elsewhere: clean infrastructure, complete trust pages, real entity details, sensible content. The failing combination is new domain plus sloppy everything else — that pairing reads as a churn-and-burn setup.
Which trust signal is most often missing?
In my experience: working, specific policy pages. Not missing entirely — present but hollow. Template text, no entity, dead contact form. It's the cheapest strong signal to fix and the one buyers most often skip because it's boring.
Do reviewers actually check the mobile version?
Typically, yes — moderation tooling in most networks renders the page at more than one viewport, and mobile is where most paid traffic lands anyway. A page that's clean on desktop and broken at 375px wide is a failed review and a failed campaign at the same time.
Can I fix trust signals after a rejection?
Mechanical ones, fast: SSL, redirects, policy pages, contact form — hours, not weeks. Then request re-review through the network's normal process. Reputation problems take longer, and account-level flags are a different fight from ad-level ones.
Check your signals before the reviewer does
Everything in the mechanical and behavior layers above is checkable in one pass. AdInfraCheck runs 17 modules per domain — WHOIS, DNS, SSL, reputation across 30+ blacklists plus Safe Browsing and VirusTotal, cloaking signals, security headers, email infrastructure, Core Web Vitals, GDPR and Google Ads compliance — and reports each module separately, so you see which layer failed instead of a single opaque score.
The part that maps closest to this article is the captures. A real browser opens your page at desktop (1440×900) and mobile (375×812), takes full-page screenshots, and records a scroll video — the same view a reviewer gets, including what happens while scrolling. Download the ZIP, look at your own page the way the review will, and fix what fails before the spend.
It's free with an account. And when you want the item-by-item version of this thinking, the full pass is in the white page checklist.