---
name: trend-landing-page
description: Build an answer-first, fully sourced landing page for a brand-new search term (a just-announced or rumored model, product, feature or event) before competitors do. Researches official and reputable news sources, separates confirmed facts from reports and rumors, writes the page with a sourced FAQ plus NewsArticle, FAQPage and BreadcrumbList JSON-LD, adds internal links and updates the sitemap and llms.txt. Use when the user names a new keyword, trend, leak or launch to cover.
---

# Trend landing page

Turn a fresh keyword (e.g. "Gemini 4 Carbon", "GPT-6 Astra pricing", "<product> shutdown") into a page that ranks and gets cited by AI answer engines **because it is the most accurate page on the topic** — not the loudest.

Real case: https://getaicodingagent.com/models/gemini-4-carbon was produced with this workflow within ~2 days of the Business Insider report. It clearly labels the model as *reported, unconfirmed*, quotes only what the report says, and keeps viral X claims ("beats Opus 5.5 and GPT-6 Astra") out because no source supports them. Docs: https://getaicodingagent.com/skills/trend-landing-page/

## Inputs

- **Term** (exact spelling people search) and 2–4 variants ("<term> release date", "<term> vs <rival>", "<term> pricing", "what is <term>").
- **Site repo** and how pages are generated (data file + template, MDX, CMS, Next.js route). Find the existing pattern for article/news pages and reuse it.
- **Production origin** for canonicals/JSON-LD.

## Step 1 — Research (do not write yet)

1. Search the term plus "announce", "blog", "docs", "pricing", "release date". Use the current year in queries.
2. Collect sources in tiers and **open each one** (never cite a search snippet):
   - **Tier 1 — official**: vendor blog, docs, changelog, pricing page, status page, SEC filing, official X/GitHub account.
   - **Tier 2 — reputable reporting**: Reuters, Bloomberg, The Verge, Business Insider, TechCrunch, The Information, Ars Technica, established trade press — with author and date.
   - **Tier 3 — secondary/social**: blogs, aggregators, X/Reddit posts, leakers. Use only to describe *that a claim circulates*, never as proof.
3. For each source record: URL, publisher, author, publish date, and the exact claims it supports (short quotes ≤ 25 words).
4. Check whether the vendor has commented ("declined to comment" is a fact worth stating).
5. If nothing Tier 1/Tier 2 exists, stop and tell the user the term is not page-worthy yet (or offer a short "what we know" stub explicitly marked unconfirmed).

## Step 2 — Fact ledger

Write a ledger before drafting:

| Claim | Status | Source(s) |
|---|---|---|
| … | CONFIRMED (official) / REPORTED (Tier 2, named outlet) / RUMORED (Tier 3 only) / FALSE-OR-UNSUPPORTED | URL(s) |

Rules: a claim is CONFIRMED only with a Tier 1 source. Numbers (prices, benchmarks, dates, context windows) need a source each. A claim that appears only on social media is RUMORED and must be written as "Posts on X claim … ; no report we could verify supports this." Unknowns go in a "What we don't know" list — that list is often what searchers want.

## Step 3 — Page structure

Title ≤ 60 chars with the term first and the top intent: `<Term>: Release Date, <Rival> Comparison & What We Know`. Meta description 140–160 chars with the one-sentence answer. URL: short, lowercase, hyphenated slug of the term.

1. **H1**: `<Term>: what we know so far` (or "explained"/"pricing" matching intent).
2. **Answer-first paragraph** (2–3 sentences): what it is, its status (released / announced / reported / rumored), the key date and source — e.g. "**X is not a released model.** It is … according to a <Outlet> report by <Author> published <date>. <Vendor> declined to comment."
3. "Last updated <date> · Status: <status>" line, plus a visible notice box if unconfirmed.
4. **What was reported / announced** — bullet list straight from the ledger, each bullet attributable.
5. **What we know / what we don't know** — two columns or lists.
6. Intent sections as H2s: release date, pricing, vs <rival>, availability ("Can I use it in <tool>?"). Answer each in the first sentence, then context. Say "none announced" rather than speculating.
7. **What it means for <your audience>** — the original, useful part: which products are affected, what to do now ("don't switch tools on a rumor").
8. **Sources** — numbered list, publisher + title + date, linked.
9. **FAQ** — 4–6 questions phrased as people search them; answers 1–3 sentences, consistent with the body.

## Step 4 — Structured data (JSON-LD)

Add three blocks (valid JSON, content must match visible text):

```json
{"@context":"https://schema.org","@type":"NewsArticle","headline":"<title>","description":"<meta description>",
 "datePublished":"YYYY-MM-DD","dateModified":"YYYY-MM-DD","mainEntityOfPage":"<canonical URL>",
 "author":{"@type":"Organization","name":"<Site>","url":"<origin>/"},
 "publisher":{"@type":"Organization","name":"<Site>","url":"<origin>/"},
 "about":[{"@type":"Thing","name":"<Term>"}],"citation":["<source URL 1>","<source URL 2>"]}
```

plus a `FAQPage` (`mainEntity` = the visible FAQ, `Question.name` + `acceptedAnswer.text`) and a `BreadcrumbList` (Home → section → page). Use `Article` instead of `NewsArticle` for evergreen explainers.

## Step 5 — Wire it into the site

- Implement through the site's generator/data (never hand-edit generated HTML).
- Internal links **to** the new page from: the home/news feed item, the hub or category page, and every existing page about related entities (e.g. each tool that could use the model). Descriptive anchors ("Gemini 4 Carbon explainer"), not "click here".
- Internal links **from** the new page to your relevant evergreen pages (comparisons, directories).
- Add to `sitemap.xml` (with `lastmod`), to `llms.txt` (one line: `- [<Term> (reported, unconfirmed)](<url>): <description>`), and to any news JSON/RSS feed.
- Build, then validate: one H1, unique title, valid JSON-LD (`python3 -c 'import json,sys;…'` or the `seo-preflight` skill), no broken links.

## Step 6 — Ship and notify

Deploy, check the URL returns 200, resubmit the sitemap in Search Console, and ping IndexNow for the new URL if the site has a key. Then record a **re-check trigger** in the project notes: what event would change the page (official announcement, pricing page live, benchmark published) and when to check again (24–72 h for hot terms).

## Output to the user

```
New page: <URL>  (status: <confirmed/reported/rumored>)
Title / description: …
Sources used: <n> (Tier1 <a>, Tier2 <b>); claims excluded as unsupported: <list>
Linked from: <pages>; sitemap + llms.txt updated; IndexNow: <status>
Re-check: <trigger> by <date>
```

## Guardrails

- Never state rumors as facts, invent dates/prices/benchmarks, or quote more than ~25 words from any source.
- Prefer "reportedly", "according to <Outlet>", "<Vendor> has not confirmed".
- When the vendor later confirms or denies, update the page (status, dateModified, ledger) the same day — that update is what keeps it ranking.