Letting a Model Compare Ad Copy and Landing Pages

The most common failure mode in ad-versus-page prompting is asking the model to "compare" two texts in one open-ended request. You get a paragraph of commentary that agrees with whichever text it read last and cites nothing. Split the job.

First, a small call that reads only the ad and returns a promise object. Keep it rigid:

{
  "offer": {"text": "", "quote": ""},
  "audience": {"text": "", "quote": ""},
  "benefit": {"text": "", "quote": ""},
  "urgency": {"text": "", "quote": ""},
  "action_requested": {"text": "", "quote": ""},
  "unstated": ["dimensions the ad leaves implicit"]
}

The unstated array matters more than it looks. If the ad never names an audience, the page cannot mismatch on audience, and a reviewer who sees a "critical" audience mismatch will stop trusting the report. Prompt for absence explicitly.

Second, the comparison call. Give the model the ad's promise object and one chunk of page text, and nothing else. Here is a template you can paste and adapt:

You are auditing whether a landing page keeps the promises made in an ad.

AD PROMISES (extracted earlier, treat as ground truth):
{{promise_json}}

PAGE SECTION:
Heading: {{section_heading}}
Text: {{section_text}}

Task: for each promise dimension (offer, audience, benefit, urgency, action),
decide one of: matched, partially_matched, contradicted, absent.

Rules:
1. Quote the exact page text that supports your decision. Copy it character
   for character. If nothing supports it, use the string "NO_EVIDENCE".
2. Do not credit the page for information a visitor would have to hunt for in
   another section. Judge only this section.
3. Severity: 3 = the visitor's reason for clicking is contradicted or missing
   above the fold; 2 = softened, vague or deferred; 1 = cosmetic wording only.
4. Never invent page text. If you cannot find a quote, mark it absent.
5. Return JSON only, matching the schema below. No prose.

SCHEMA:
{{schema_json}}

Two rules do the heavy lifting. The exact-quote rule prevents the model from paraphrasing the page into agreement with the ad, which is the failure that makes LLM audits unusable in a review meeting. The "judge only this section" rule prevents the merge step from collapsing into a single overall verdict with no location attached.

The report should be one record per mismatch, with both quotes, a severity, and a suggested fix that names the element to change. This shape is deliberately close to how structured data is organized elsewhere on the page, which makes it easy to hand to a designer or a copywriter Google's structured data guidance.

{
  "section_heading": "string",
  "matches": [
    {
      "dimension": "offer | audience | benefit | urgency | action",
      "status": "matched | partially_matched | contradicted | absent",
      "ad_quote": "string",
      "page_quote": "string or NO_EVIDENCE",
      "severity": 1,
      "fix": {
        "element": "headline | subhead | cta_button | body | proof_block",
        "suggested_text": "string",
        "rationale": "one sentence"
      }
    }
  ]
}

A severity scale only works if the anchors are concrete. Before you run this across a campaign, decide what each level means for your business and write it into the prompt with one example per level. A workable rubric:

The decision rule that saves the most time: route by severity, not by volume. A campaign report with forty severity 1 items and one severity 3 item should trigger exactly one action. If you route everything, nothing gets fixed. The same logic appears in practitioner audit frameworks that score a page across five areas and recommend revising at the middle band while pausing or rerouting traffic in the bottom band the paid search promise audit.

One calibration tip. Run the comparison on a page you already know is broken, and on one you know is fine. If both come back with severity 3, your rubric is too aggressive and you will spend the next month arguing with the model's output instead of using it.

Take an ad that reads: "Emergency AC repair tonight. Flat $89 diagnostic. Book online in 60 seconds." Extracted promises:

• offer: flat $89 diagnostic
• audience: homeowners with a broken AC
• benefit: repair tonight
• urgency: tonight
• action: book online

Now the page opens with "Comfort for every season" and a hero image of a family on a sofa. A model comparison against that hero section returns, plausibly:

That table is the deliverable. It shows the page fails on the two dimensions that mattered most, quotes both sides, and leaves a fix suggestion per row. Note that the page could contain the words "AC repair" throughout and still produce this result, which is the point a keyword repetition check misses: match is about meaning, not shared nouns.

The same pattern applies to ecommerce, where the ad names a product or discount and the destination opens on a broad collection grid, and to B2B, where a specific audit offer lands on a generic contact page the message match checklist. The four-field promise extraction catches all of these because it does not care what the product is.

A page that runs to several thousand words will not fit reliably in one call alongside your schema and instructions. Splitting by heading is the right move for two reasons. First, headings are the structural line between a promise and the section that keeps or breaks it. Second, eye-tracking research identifies a layer cake pattern where users scan headings and skip the paragraphs beneath them the writing-for-the-web guide, so a mismatch buried under a reassuring heading is a real risk, not a technicality.

The pipeline:

1. Fetch the page and convert to plain text.
2. Split on heading elements, keeping each heading with the text that follows.
3. Cap each chunk at a token budget you choose, and summarize anything above it before comparison.
4. Run the section comparison call once per chunk against the same promise object.
5. Merge the results, then sort by severity.

When you summarize an oversized section, do not ask for a summary in the ordinary sense. Ask for extraction: "List every claim this section makes about price, timing, audience and next step, quoting each verbatim." A narrative summary will drop the exact phrase you need as evidence, and the merge step will then have nothing to cite.

For the merge, a second small call works: give the model all section-level reports as JSON and ask it to return the top issues plus a per-dimension verdict, deduplicating rows that quote the same page text. Keep this call cheap. It is sorting, not judging, and you can also do it in ordinary code, which is more predictable and free.

Two practical limits. Cap tokens per call rather than per page, so a runaway section cannot blow the context window. And keep the promise object in every call: if you re-extract promises for each section, you will get slightly different promise definitions per section, and the merged report becomes internally inconsistent.

Run the comparison at three moments: before a campaign launches, after any change to the page hero, and when a campaign's conversion rate drops while spend holds steady. The middle trigger is the one teams skip, and it is the one that catches the most drift, because hero edits happen for reasons unrelated to the ads pointing at them.

Store the JSON reports next to the campaign, not in a chat window. A report with quotes and severities is auditable months later; a chat thread is not. If you want a written checklist to pair with the model output, the five-point version covering headline, subheadline, visuals, CTA and tone is a good manual companion the 5-point message match checklist, and it also flags the trap of creating a separate page for every keyword, which builds technical debt faster than it fixes mismatches.

For teams running this across many campaigns and pages, the bottleneck becomes plumbing rather than prompting: one model for the extraction, another for the comparison, a third for the merge, each with its own key and pricing. Quanta Inference exposes text, image and embedding models through a single OpenAI-compatible API with prepaid US-dollar pricing, which removes that per-provider overhead when you scale the check from one campaign to all of them. And if what you actually need is the finished artifact rather than the pipeline, a Quanta expert can take the ads and pages, run the audit and hand back the report and the rewrite, which is often the faster path for a team that already knows its pages are drifting and wants the fixes drafted Quanta Experts.

Two habits keep the output useful. First, keep a small set of hand-scored examples and re-run them whenever you change the prompt or schema; if the model's severities drift, you will see it before your stakeholders do. Second, treat suggested fixes as drafts. The model is good at spotting that "tonight" became "same week" and bad at knowing your legal team will not approve an absolute claim. The check finds the mismatch; a human still decides the wording.