U Ranket
⌘K

Article quality

What's actually in an Ranket article — structure, citations, schema, CTAs. Matches premium publisher standards (3K+ words, full JSON-LD bundle).

Every Ranket article targets the structural depth of a top-of-funnel premium blog post — the kind a content team would take 4-6 hours to write. The pipeline enforces this with explicit constraints at every stage.

Target shape

Word count          2,500-3,500 words
H2 sections         8-12, each 250-400 words
H3 sub-sections     2-4 per H2 (= 24-48 total sub-sections)
TL;DR opener        3-5 bullets at the very top
FAQ block           8-12 questions, each with 40-90-word answer
Comparison tables   1-3 inline tables
Internal links      12-15 to the brand's own pages
External links      1 YouTube, up to 3 Reddit, 2-3 authority links
Facts cited         8+ verbatim from competitor research with source links
CTAs                3 strategic touchpoints + 2-3 inline product mentions
Images              1 hero + 3-5 inline section images
JSON-LD             Full graph (8+ entity types — see below)
Read time           Emitted in payload meta (words ÷ 200)

Structure rules

TL;DR opener

Every article opens with a “For skimmers:” block immediately after the hero image, before the intro paragraphs:

**For skimmers:**
- The most important conclusion / number / answer (always the first bullet)
- Second key takeaway
- Third
- Fourth (optional)
- Fifth (optional)

3-5 bullets, each 8-20 words. This is what readers see before scrolling — critical for SEO (LLMs and skimmers extract their summary here) and for engagement metrics.

Sections with depth

The brief generates 8-12 H2 sections, each with:

  • A specific angle (not “introduce X” — “the counterintuitive finding that Y”)
  • 4-6 key points the writer MUST cover
  • 2-4 H3 sub-headings for structure
  • A target word count of 250-400 words

The draft prompt enforces ±20% on per-section word count and ±10% on total. Articles that come back too short get flagged and re-run.

Step-numbered methods for how-to articles

When the strategy picks format: howto, main procedure sections get numbered:

## Step 1: Set up the camera
## Step 2: Choose your exposure brackets
## Step 3: Capture the bracketed shots
...

Or for “alternative methods” articles:

## Method 1: Use the iPhone Panorama trick
## Method 2: Use the Google Street View app
## Method 3: Use a third-party stitcher

Intro / context / FAQ / conclusion sections stay unnumbered. The numbering anchors structure for readers AND drives the HowTo schema graph.

FAQ block

Premium articles have 8-12 FAQ entries at the bottom, just before the conclusion. Each:

  • Question is a real query (from the SERP’s “People Also Ask” or natural follow-up)
  • Answer is 40-90 words, direct, written to win a featured snippet
  • Rendered as H3 under an H2 “Frequently asked questions”

The whole block also emits as FAQPage JSON-LD for SERP rich results.

Conclusion

Final H2 — never titled “Conclusion” because that’s lazy. The brief picks something specific: “What this means for your stack”, “Where to start tomorrow”, “The bottom line for your listings”. The brief’s CTA gets woven into the closing paragraph naturally, not bolted on as a separate sales pitch.

Visual hierarchy patterns

The draft prompt instructs the writer to use 2-4 of these throughout the article:

Callout box

> 🏠 **Skip the manual workflow.** BrightShot's AI does the photo enhancement in 15 seconds — try the [free plan](/pricing).

For brand-aligned shortcuts. 1-2 per article max.

Pros / Cons block

**Pros**
- Specific benefit 1
- Specific benefit 2

**Cons**
- Specific drawback 1
- Specific drawback 2

Used in any section comparing two approaches.

When-to-use

**When to use this:** scenario A, scenario B
**When NOT to use this:** scenario C, scenario D

For tool / method recommendations where the right answer depends on context.

Key-takeaway pull-quote

> **Key insight:** 87% of buyers say listing photos are the single most important factor in their interest level.

For a specific number or insight worth pulling out visually.

Inline template / checklist

**The 7-day pre-listing checklist:**
- Day 1: declutter living + dining
- Day 2: deep-clean kitchen
- Day 3: stage primary bedroom
...

For roadmap, playbook, or planning topics. Copy-able + screenshot-friendly.

CTA placement

3 strategic + 2-3 inline = 5-6 touchpoints per article, distributed across the body:

Strategic CTAs

  • Intro CTA — implicit/soft, woven into the intro paragraph. Don’t sell; plant the brand as an option.
  • Mid-content CTA — soft pitch in a callout box, placed after a section that demonstrates the problem clearly.
  • End CTA — the brief’s specified CTA, woven into the conclusion naturally.

Inline product mentions

Short contextual brand references woven into prose where they fit grammatically:

- Inline link:        Most editors take 10 minutes ([BrightShot](url) does it in 15 seconds).
- Parenthetical:      Manual stitching takes 8-12 hours per listing — BrightShot cuts that to a single click.
- Trailing callout:   "(Try the free plan →)" at the end of a paragraph

One per section maximum. Must fit the prose grammatically; if forcing one disrupts the flow, skip that section.

Citations and facts

The pipeline includes a data points stage between brief and draft. We send the top 5 competitor pages we scraped (during research) to Claude Haiku and ask for 12-20 cite-able facts:

[w5|stat]         87% of buyers say listing photos are the most important factor
                  source: https://nar.realtor/research/...

[w4|comparison]   Matterport pricing starts at $69/mo per Pro license
                  source: https://matterport.com/pricing

[w4|date]         Google Street View added 360° upload support in January 2024
                  source: https://support.google.com/maps/...

Each fact has:

  • A kind: stat | price | date | quote | tool | comparison | limitation | definition
  • A weight 1-5 — how citable / useful in the final article
  • A verbatim source URL and source title

The draft prompt requires the writer to weave in at least 8 facts verbatim or near-verbatim, and cite each one as an inline markdown link [source](sourceUrl). We never invent specific numbers, prices, or quotes — only the verifiable ones from the fact library make it into the article.

Comparison tables

The brief produces 1-3 tables per article. Each:

  • 3-6 columns (first column identifies the row entity)
  • 3-10 rows (entity names — products, tools, methods)
  • A short caption above the table
  • Anchored to a specific H2 section (afterH2 field)

The draft renders each as a proper Markdown table, fills cells from competitor research / brand profile, and never invents specific numbers (uses ranges or “N/A” when unknown).

Required for format: comparison articles. Optional but encouraged for other formats — a “best of” listicle benefits from a feature/price matrix; a how-to benefits from a method comparison.

Internal linking

The brief picks 12-15 internal links from the brand_pages table — actual pages the brand has on their site. Each link:

  • Has a natural anchor text that varies (no repeating “click here”)
  • Points to a real URL from the scraped site
  • Is distributed across sections (max 2 per section)

The draft enforces using ALL the suggested internal links. Articles that drop links fail review. This is intentional — it forces every article to genuinely link to the brand’s other pages, building topical clusters that compound over time.

Hero and section images

  • Hero image at the very top: narrative scene with a person or concrete context, NOT abstract product/icon shots. Required for og:image and Twitter Card.
  • Section images: ~half the sections get an image, spread out (never two in adjacent sections)
  • All images generated by Fal nano-banana with prompts derived from the section’s content + brand’s visualStyle from the profile
  • Each image has alt text including a relevant LSI keyword (not the primary keyword stuffed in)
  • Hero alt is the article’s primary visual scene, naturally readable

The JSON-LD bundle

Every article ships with a full structured-data graph that matches premium publisher standards:

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Person",
      "@id": ".../author-pau-guirao",
      "name": "Pau Guirao",
      "jobTitle": "Founder",
      "url": "https://bright-shot.com/blog/author/pau/",
      "worksFor": { "@id": "...#organization" }
    },
    {
      "@type": "BlogPosting",
      "@id": "...#article",
      "headline": "...",
      "description": "...",
      "datePublished": "...",
      "dateModified": "...",
      "image": "https://...",
      "author": { "@id": ".../author-pau-guirao" },
      "publisher": { "@id": "...#organization" },
      "mainEntityOfPage": { "@id": "...#webpage" }
    },
    {
      "@type": "HowTo",
      "@id": "...#howto",
      "totalTime": "PT16M",
      "step": [
        { "@type": "HowToStep", "position": 1, "name": "..." },
        ...
      ]
    },
    {
      "@type": "WebPage",
      "@id": "...#webpage",
      "isPartOf": { "@id": "...#website" },
      "primaryImageOfPage": { "@type": "ImageObject", "url": "..." }
    },
    {
      "@type": "BreadcrumbList",
      "itemListElement": [
        { "position": 1, "name": "Home", "item": "..." },
        { "position": 2, "name": "Blog", "item": ".../blog/" },
        { "position": 3, "name": "...", "item": "..." }
      ]
    },
    {
      "@type": "Organization",
      "@id": "...#organization",
      "name": "BrightShot",
      "url": "...",
      "logo": { "@type": "ImageObject", "url": "..." }
    },
    {
      "@type": "WebSite",
      "@id": "...#website",
      "url": "...",
      "publisher": { "@id": "...#organization" }
    },
    {
      "@type": "WebApplication",
      "@id": "...#webapp",
      "name": "BrightShot",
      "applicationCategory": "MultimediaApplication",
      "operatingSystem": "Web",
      "publisher": { "@id": "...#organization" }
    },
    {
      "@type": "FAQPage",
      "@id": "...#faq",
      "mainEntity": [
        { "@type": "Question", "name": "...", "acceptedAnswer": { "@type": "Answer", "text": "..." } },
        ...
      ]
    }
  ]
}

What each entity does

  • BlogPosting — the article itself (subtype of Article for richer SERP treatment)
  • Person — author byline + jobTitle + bio link (boosts E-E-A-T signals)
  • HowTo — only on how-to articles; powers Google’s HowTo rich card
  • WebPage — connects article to site
  • BreadcrumbList — site hierarchy for SERP breadcrumbs
  • Organization — publisher entity
  • WebSite — site-level metadata (search-action friendly)
  • WebApplication — the brand’s product, structurally linked from every article
  • FAQPage — powers FAQ-snippet rich results

The graph is consistent across articles so search engines and LLMs can build a coherent picture of the brand.

Social-share metadata

Every article ships with Open Graph + Twitter Card meta in a meta object the CMS can render in <head>:

{
  "canonicalUrl": "https://bright-shot.com/blog/...",
  "ogTitle": "...",
  "ogDescription": "...",
  "ogImage": "https://cdn.fal.media/files/.../hero.png",
  "ogType": "article",
  "ogUrl": "https://bright-shot.com/blog/...",
  "ogArticlePublishedTime": "2026-05-15T09:00:00Z",
  "ogArticleModifiedTime": "2026-05-15T09:00:00Z",
  "twitterCard": "summary_large_image",
  "twitterTitle": "...",
  "twitterDescription": "...",
  "twitterImage": "https://cdn.fal.media/files/.../hero.png",
  "readTimeLabel": "16 min read"
}

Without these, social shares fall back to your site-level defaults, which usually produces generic previews.

The plan-then-execute architecture

A naive pipeline runs all 8 stages serially each time an article is needed. That’s slow, expensive, and prone to coordinated failure.

Ranket separates them:

PLAN (runs when keyword is scheduled, ahead of time)
  1. Research       SERP top 10, PAA, related kws
  2. Scrape         Top 5 competitor URLs cleaned
  3. Strategy       Sonnet — format, word count, outline, links
  4. Brief          Sonnet — section-by-section spec
  5. Data points    Haiku — 12-20 cite-able facts
  → stored in calendar row as `plan` JSONB

EXECUTE (runs on the scheduled day)
  6. Draft          Sonnet, max 24K tokens, uses brief + facts
  7. Polish         Sonnet refinement pass
  8. Images         Fal nano-banana × 3-5
  9. Backlinks      Optional, if matching offer exists
  10. Assemble      Markdown + JSON-LD + meta + signed payload

This split:

  • Makes the daily cron fast (~3-5 min per article vs ~10-15)
  • Spreads cost over time
  • Allows previewing planned strategy/brief days in advance
  • Reduces coordinated failure (one bad plan doesn’t poison generation; one bad generation doesn’t lose the plan)

Cost per article

Plan
  Research (SERP + scrape)              $0.02
  Strategy (Sonnet)                     $0.04
  Brief (Sonnet)                        $0.07
  Data points (Haiku)                   $0.01
                                       ──────
                                        $0.14

Generate
  Draft (Sonnet, 24K max)              $0.30
  Polish (Sonnet)                      $0.16
  Images (Fal × 4)                     $0.20
  Backlinks (Sonnet, optional)         $0.02
  Assemble                             $0.00
                                       ──────
                                        $0.68

Total per article                       $0.82

Limits

  • Article max length: 3,500 words (brief enforces this)
  • Draft max tokens: 24K (Sonnet 4.6 ceiling — sufficient for 3.5K word output)
  • Hero + section images: max 6 per article
  • Internal links: capped at 15
  • External links: 1 YouTube + 3 Reddit + 3 authority = max 7
  • FAQ block: max 12 questions
  • Comparison tables: max 3 per article

Quality checks

Before assemble, the polished article passes a checklist:

  • Word count within 10% of target
  • All planned internal links present
  • ≥8 facts cited with source links
  • FAQ block exists with 8+ entries
  • TL;DR block exists at top
  • All comparison tables rendered
  • Hero image placeholder resolved
  • No unresolved {{embed:}} placeholders

Articles that fail these checks return to the pipeline for one retry; if they fail again, they’re marked failed for manual review.

Was this page helpful?