datntdangson-hue/skills

Research Landing Page Builder

Purpose

Use this skill for future projects, not just Gravel Host.

The skill turns a named subject into a research-first landing page:

Discover → Research → Verify → Keyword/Intent Map → Information Architecture → Landing Page → Conversion → QA → Freshness

Possible subjects:

• brand
• product
• SaaS/software
• hosting provider
• service
• real-estate project
• developer/company
• affiliate merchant
• comparison subject
• other commercial/research entity

Never assume the Gravel Host structure fits every subject. Build the structure from the subject's actual search intent and evidence.

Step 0 - Define the page job

Before research, determine:

• Primary entity/topic
• Target audience
• Primary user task
• Desired conversion, if any
• Existing site/project context
• Intended URL
• Whether this is a hub, landing page, comparison page, project page, or research profile

Default philosophy:

Research → Evidence → Decision support → Conversion

Conversion may be:

• affiliate click
• lead form
• contact
• consultation
• booking
• download
• no commercial CTA

Do not force affiliate patterns onto non-affiliate projects.

Step 1 - Existing-content audit

Before creating a URL:

1. Search the current CMS/site for the entity and close variants.
2. Find existing posts/pages/taxonomy archives.
3. Check whether deleted URLs may still be indexed.
4. Identify cannibalization risk.
5. Decide whether to keep, merge, redirect, replace, or create.

Do not create a new URL just because a keyword variation exists.

Step 2 - Keyword and intent research

Use available keyword tools plus live search.

Research:

• exact entity name
• reviews/reputation
• legitimacy/trust
• price/cost
• features/specifications
• location/availability
• policies/warranty/refund
• use cases
• problems/complaints
• alternatives
• comparisons
• questions/how-to
• commercial/deal intent when relevant

Cluster by intent, not by keyword spelling.

For each cluster record:

• primary query
• variants
• intent
• evidence of demand
• SERP type
• whether it belongs on the landing page
• whether it deserves a separate deeper URL

Do not make an H2 for every autocomplete phrase.

Step 3 - Entity research

Research primary sources first:

• official website
• official documentation
• legal/policy pages
• product/project specifications
• pricing
• public company/developer information
• official maps/plans where relevant

Then use independent sources:

• customer/user feedback
• reputable reviews
• regulatory/public records where appropriate
• credible news/research
• community experience where useful

For real estate, distinguish:

• official legal/project information
• developer marketing claims
• broker/sales claims
• observed construction/progress
• market commentary

For health/finance/high-stakes subjects, apply the appropriate higher evidence standard and do not turn the page into personalized professional advice.

Step 4 - Evidence ledger

Before writing, create an internal evidence ledger:

| Claim | Value | Source | Source type | Checked date | Confidence | Notes/conflict |

Classify important claims as:

• Verified
• Provider/owner claim
• Independent observation
• User/customer report
• Unknown/conflicting

If sources conflict, do not silently choose the convenient value. Surface the discrepancy when it matters.

Never invent:

• hands-on testing
• visits
• interviews
• ownership
• performance results
• prices
• dates
• customer counts
• legal status

Step 5 - Freshness

Treat changeable facts as snapshots.

Fresh-check before publication:

• price
• promotions
• availability/inventory
• product count
• specifications
• policies
• warranty/refund
• locations
• construction/progress
• sales policy
• support claims
• ratings/review counts
• legal/project milestones

Show "Last researched", "Last checked", or a Research Log when freshness materially helps the user.

Step 6 - Choose the landing-page architecture

Build architecture from intent.

Common modules, used only when relevant:

1. Hero
2. Sticky/anchor navigation
3. At a Glance
4. What I Researched
5. Overview / Review
6. Trust / legitimacy / legal status
7. Pricing / cost / payment
8. Features / specifications
9. Use cases / sub-products / unit types
10. Performance / progress / implementation
11. Location / map
12. Policies / warranty / refund
13. Customer/user feedback
14. Evidence: "What the entity says" vs "What I could verify"
15. Alternatives / comparisons
16. FAQ
17. Conversion block
18. Sources / methodology
19. Research log

Do not include modules that do not match user intent.

Step 7 - Heading map

Use one H1.

H1 should define the entity/page purpose clearly.

H2 = major intent cluster. H3 = meaningful sub-intent.

Rules:

• natural language
• no keyword stuffing
• same-intent variants consolidated
• important information early
• semantic HTML
• page remains understandable without search-engine context

Step 8 - Research-first writing

Voice:

• human
• specific
• concise
• evidence-aware
• transparent about uncertainty
• useful before persuasive

Prefer:

• "The official page states..."
• "I found..."
• "The current policy says..."
• "I could verify..."
• "I found conflicting information..."
• "Checked on [date]..."

Avoid:

• empty hype
• guaranteed outcomes
• unsupported superlatives
• fake scarcity
• fabricated testing
• generic AI filler
• declaring something safe/legit/best solely from marketing or ratings

If the page is a sales/lead page, persuasion must still be grounded in verified project/product facts.

Step 9 - Conversion design

Conversion comes after enough information to support a decision.

Possible placement:

• Hero: secondary CTA
• contextual CTA after a relevant research section
• primary conversion block later in the page

Affiliate:

• disclose clearly
• use sponsored/nofollow as appropriate
• verify offer before publishing

Lead generation:

• explain what the visitor receives
• do not fabricate scarcity, inventory, price, or official status

SEO + Google Search Ads hybrid mode

When the user wants one landing page to serve both organic SEO and Google Search Ads, use hybrid mode rather than creating a thin Ads-only clone by default.

Principle:

Fast answer for paid traffic + deep original research for organic traffic + one transparent conversion path

Requirements:

• Use the research landing page itself as the Google Ads Final URL.
• Do not use an affiliate redirect URL as the ad Final URL.
• The page must provide substantial standalone value even if the visitor never clicks an outbound CTA.
• Identify the publisher/researcher clearly.
• If the site is independent of the researched brand/entity, say so prominently near the hero when confusion is plausible.
• Do not imply official affiliation, endorsement, ownership, or authorization without evidence.
• Hero should answer quickly: what the page is, who researched it, freshness date, primary research CTA, and a clearly labeled secondary commercial CTA.
• Keep conversion CTA useful but subordinate to research.
• Put deeper SEO clusters below the quick-answer sections.
• Add evidence/source context to material facts.
• Add customer/user feedback research when relevant, including negative signals.
• Add About, Contact, Privacy, and disclosure/trust navigation where commercially relevant.
• For affiliate offers, state the commercial relationship clearly and use appropriate sponsored/nofollow attributes.
• Avoid doorway/bridge-page behavior: do not make the page merely a short intermediary whose main purpose is sending the visitor elsewhere.
• Keep ad copy, keyword intent, and landing-page content aligned.
• Check that the destination is crawlable and usable on common desktop/mobile browsers.
• Preserve one canonical research URL unless a genuinely distinct intent justifies another page.

Recommended hybrid ordering:

1. Transparent Hero
2. Optional compact offer/deal strip
3. Quick answer / At a Glance
4. Review / core decision support
5. Trust / legitimacy / legal evidence
6. Pricing
7. Product/use-case clusters
8. Performance/specifications
9. Evidence: claims vs verification
10. Customer feedback research
11. Policies/refund
12. Comparison where justified
13. Full offer/conversion block
14. FAQ
15. Methodology/sources
16. Research log
17. Trust footer

Deal placement rule

For SEO + Google Search Ads hybrid pages, do not place a large affiliate/deal block above the Hero by default.

The Hero must establish:

• what the page researches
• who publishes/researched it
• independent/official relationship when relevant
• freshness
• primary research action

If early commercial visibility is useful for paid traffic, place a small, clearly labeled offer strip immediately after the Hero. It may contain:

• current discount/offer
• coupon code
• concise "Check offer" action
• commercial/affiliate context when needed

The compact strip must not visually dominate the Hero or replace research content.

Keep the full conversion/deal block later in the page, after substantial original research such as review, pricing, evidence, policies and/or customer signals.

Default flow:

Hero → compact deal strip → research → full deal block → FAQ/methodology/trust

Exceptions:

• For a true coupon/deal page whose primary user intent is explicitly a coupon, the offer can be more prominent.
• For non-commercial research pages, omit the deal strip entirely.
• For lead-generation projects, adapt this rule to a compact lead CTA rather than an affiliate offer.

Reasoning: preserve research-first positioning and standalone page value while still giving paid-search visitors fast access to a relevant offer.

Hybrid quality gate:

• Page identity/publisher is obvious.
• Independent status is disclosed when relevant.
• Final URL is the useful research page, not an affiliate redirect.
• Above-the-fold content answers the ad/query intent quickly.
• Page has substantial original value beyond outbound links.
• Material commercial claims have source/check context.
• Customer feedback is balanced and evidence-led.
• Conversion is not the dominant purpose of the page.
• Trust/legal pages are easy to reach.
• Mobile paid-traffic experience is fast and readable.
• SEO sections remain crawlable and are not hidden only for search engines.

Step 10 - Visual system

Landing page should be scan-friendly rather than a wall of prose.

Desktop:

• 1100–1200px typical max width unless project design says otherwise
• clear hero
• section rhythm
• cards/tables only when they improve comprehension
• evidence blocks
• strong hierarchy

Mobile:

• intentionally redesigned single-column flow
• readable type
• no overflowing tables
• horizontal anchor nav when useful
• full-width primary CTA when appropriate
• compact stats may use 2 columns

Reuse the site's design system where possible. Use page-specific CSS when the page is sufficiently unique.

Step 11 - Images and media

Use media only when it adds evidence or comprehension.

Prioritize:

• official/product/project imagery with appropriate rights
• screenshots of relevant interfaces/data when permitted
• maps/plans/specifications
• original diagrams
• original/generated supporting visuals when factual precision is not compromised

Do not use unrelated stock images merely to fill space.

Add descriptive alt text.

Step 12 - SEO and crawl quality

Follow current Google Search Essentials and Bing Webmaster Guidelines.

Core rules:

• people-first, original value
• one focused primary topic per URL
• clear entity definition
• crawlable internal links
• stable canonical URL
• correct redirects for moved content
• logical H1–H6
• useful title/meta
• visible key information
• accurate structured data only when it matches visible content
• no duplicate/thin affiliate pages
• no keyword stuffing
• no scaled low-value pages

A landing page must stand on its own as useful research even if the visitor never clicks the conversion CTA.

Step 13 - Structured data

Use only schema supported by visible content and page type.

Possible types:

• Organization
• Product
• SoftwareApplication
• FAQPage where eligible/appropriate
• BreadcrumbList
• Article/Review only when the page truly meets the type

Never add fake Review/AggregateRating markup.

Step 14 - Implementation workflow

Before code:

1. Read current theme/template/CSS/helpers.
2. Check git status.
3. Identify shared vs page-specific components.
4. Preserve existing pages.

Implementation:

• use a dedicated template when the entity needs a unique landing experience
• use page-specific stylesheet when appropriate
• conditionally enqueue it
• version static assets with filemtime when using WordPress
• keep JS minimal
• use semantic HTML
• make critical research content server-rendered/crawlable

After code:

• PHP/template lint
• CSS/format checks
• git diff --check
• desktop/mobile inspection where possible
• validate links/anchors
• validate CTA and disclosure
• do not push unless requested

Step 15 - Quality gate

Do not mark complete until:

Research

• Existing-content/cannibalization audit complete
• Keyword intent map complete
• Primary sources checked
• Independent evidence checked where relevant
• Material facts have checked dates
• Conflicts/unknowns are not hidden
• No fabricated experience

Content

• One H1
• H2/H3 map follows intent
• No keyword stuffing
• Key answer appears early
• Research provides value independent of CTA
• Claims are appropriately attributed
• Methodology/sources included when useful
• Freshness mechanism included for changeable topics

Conversion

• CTA matches project goal
• Conversion does not dominate research
• Affiliate disclosure where needed
• No fake urgency/scarcity

Technical

• Canonical/URL strategy correct
• Internal links crawlable
• Responsive
• Accessible enough for normal use
• Images have useful alt text
• Structured data is truthful
• Syntax/lint checks pass
• git diff --check passes

Reusable output format

When invoked, return/work through:

1. Entity + page goal
2. Existing-content audit
3. Keyword/intent map
4. Evidence ledger
5. Conflicts/unknowns
6. Recommended landing-page architecture
7. H1/H2/H3 map
8. Wireframe
9. Copy/data plan
10. Implementation files
11. QA results
12. Freshness/update plan
13. Push status

Project adaptation examples

Hosting/SaaS

Review, legit, pricing, performance, features, support, refund, comparisons.

Real estate

Project overview, legal/developer facts, location, planning, product types, floor plans, construction progress, price/policy when verified, buyer/investor questions, lead CTA.

Supplement/product brand

Brand/entity, ingredients/specs, evidence boundaries, price, usage context, policies, customer signals, comparisons. Avoid unsupported health claims.

Affiliate merchant

Research/reputation, product range, shipping/returns, pricing, customer signals, coupon only after useful research.

The framework is reusable; the research determines the page, not the template.

Product understanding requirements

Research pages must explain what the product is, what it is used for, what problem it solves, how it works, who needs it, who may not need it, product types or tiers, what important specifications mean in real use, provider claims versus verified facts, limitations, realistic alternatives, and buyer checks before purchase. For technical products, translate specifications into practical consequences instead of listing features. Put an early product explainer before detailed pricing when appropriate. Conversion and affiliate calls to action come after understanding, verification, comparison, limitations, and use-case fit.

Clear section purpose and no-persona rule

Every major section must answer one explicit buyer question. Avoid vague review labels when the body does not clearly answer them.

For a general "Review" section, use it as a research summary: state the most important verified facts, material caveats, and what those findings mean for a buyer. Do not fill it with generic praise, generic pros/cons, or repeated feature lists.

For "Is [Brand] Legit?" intent, do not answer with a vague verdict. Reframe the section around concrete verification: who operates the service, current legal identity where published, terms and policies, billing/refund mechanisms, SLA or service commitments, support channels, and other directly checkable signals. Explicitly state what those signals do not prove, such as real-world performance or support quality.

Avoid first-person editorial voice in research landing pages. Do not use I, me, my, "I checked", "I found", "I think", or "I would". Prefer neutral constructions such as "Research found", "The current terms state", "The provider lists", "This could be verified", "Available evidence does not establish", and "Buyers should check".

Before publishing, run a section-overlap audit. If two sections repeat the same facts, assign separate jobs: for example, "What is included in the purchase?" explains the components of the product, while "What affects performance?" explains how those components change real-world outcomes.

Research report editorial model

Public-facing research landing pages are English-only unless a different language is explicitly requested for that page.

Treat the landing page as a continuous research report, not a collection of SEO sections or generic feature cards. A reader should be able to start with little category knowledge and finish with enough context to understand the product, its components, evidence, trade-offs, alternatives, and buying checks without repeatedly leaving the page to search elsewhere.

Every material product component must be reported in five layers:

1. What it is.
2. What it does.
3. Why it matters in real use.
4. What the provider claims and what evidence supports or limits that claim.
5. How it compares with another tier, deployment model, realistic alternative, or buyer requirement.

Do not write generic statements such as "CPU and RAM matter", "DDoS protection is included", or "choose a nearby location" without explaining the mechanism and buyer consequence. Translate specifications and features into practical effects, limitations, and decision criteria.

Use a report flow that answers the next likely buyer question: Category context -> Product purpose -> Product anatomy -> How it works -> Evidence/verification -> Product-specific workloads -> Pricing and plan economics -> Performance implications -> Infrastructure/location -> Management/backups/support -> Policy/legal conditions -> Customer evidence -> Alternatives/comparison -> Limitations -> Buyer checklist -> Commercial offer.

Comparison must be like-for-like. Compare equivalent workload, resources, management responsibility, billing term, location, support scope, refund conditions, and included features. Do not compare headline entry prices from unlike products.

Provider claims, directly verified facts, independent evidence, calculations, and editorial explanations must remain distinguishable. When sources conflict, report the conflict and explain its buyer impact rather than silently selecting one value.

Avoid first-person voice. Avoid filler summaries that merely repeat later sections. Each section must add evidence, explanation, comparison, or a decision-relevant conclusion.