Skip to content
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
192 changes: 192 additions & 0 deletions docs/content/features/landing-page-social-proof-pack-from-old.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,192 @@
# TuxSEO Landing-Page Social Proof Pack (ported from TuxSEO Old)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Missing YAML frontmatter

Every other file in docs/content/features/ includes a YAML frontmatter block with title, description, keywords, and author. This file has none, which will likely cause issues with whichever static-site generator (or docs renderer) processes this directory — pages may fail to build, render without metadata, or appear without a title in navigation.

Compare with the sibling file docs/content/features/blog-post-suggestions.md:

Suggested change
# TuxSEO Landing-Page Social Proof Pack (ported from TuxSEO Old)
---
title: Landing-Page Social Proof Pack
description: Production-ready social proof snippets and evidence requirements for the TuxSEO landing page.
keywords: TuxSEO, social proof, landing page, conversion, testimonials
author: Rasul Kireev
---
# TuxSEO Landing-Page Social Proof Pack (ported from TuxSEO Old)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Legacy artifact in filename

The -from-old suffix in landing-page-social-proof-pack-from-old.md appears to be a carry-over label from the porting process rather than an intentional production filename. If this document is meant to live in the repo long-term and potentially be rendered in the docs site, consider renaming it to landing-page-social-proof-pack.md to keep the URL and navigation label clean.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!


Owner: Scribe
Date: 2026-03-11
Source intent: Rebuild a conversion-ready social-proof layer using verified claims only.

Comment on lines +1 to +6
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Document audience mismatch for this directory

The docs/content/features/ directory is intended for end-user-facing feature documentation, as outlined in docs/AGENTS.md ("Write for Users, Not Developers — Focus on what users can do with the feature"). This file is an internal content-strategy / marketing planning artifact (snippet library, evidence matrix, handoff checklist) aimed at the product/content/ops team — not at TuxSEO end users.

Consider whether this document belongs here, or whether it would be better placed in a dedicated internal planning directory (e.g., docs/internal/ or docs/content/marketing/) to avoid confusion with user-facing docs and to keep the features/ path clean for renderable end-user pages.

## 1) Social proof snippet library (with confidence variants)

Use the **Strong proof** variant only when evidence is confirmed and permission is cleared.
Use **Pending validation** variant while evidence is being collected.
Comment on lines +1 to +10
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

Reframe the opening around user value, not internal provenance.

This starts with internal metadata and a legacy-port note, then immediately drops into validation rules. In docs/content/features/, the page should first explain what teams can accomplish with this pack and why it improves conversions before getting into proof variants or evidence handling. As per coding guidelines, docs/**/*.{md,mdx} should "explain business value before technical details" and "write documentation focused on what users can do with features, not implementation details."

🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@docs/content/features/landing-page-social-proof-pack-from-old.md` around
lines 1 - 10, Reframe the document to lead with user/business value: replace the
current opening lines ("TuxSEO Landing-Page Social Proof Pack (ported from
TuxSEO Old)" and the Owner/Date/Source intent metadata) with a short,
user-facing intro that explains what teams can accomplish with this pack and how
it improves conversions (e.g., increase trust, lift CTA performance, easy
verified claims workflow), then keep the "Social proof snippet library (with
confidence variants)" section and the notes about "Strong proof" and "Pending
validation" but move the provenance metadata (Owner/Date/Source intent) to the
end or a separate "Implementation notes" section; ensure the first paragraph
focuses on business outcomes and actionable team benefits before any technical
or validation rules.


---

### SP1 — Hero trust strip: active usage signal
**Placement:** Directly below hero CTA
**Strong proof copy:**
- "Used by **{{active_projects_count}} active projects** to ship SEO content consistently."

**Pending validation copy:**
- "Used by early SaaS teams building a repeatable SEO workflow."

**Evidence required:**
- Product DB count definition + query snapshot for `active_projects_count` (last 30 days)
- Date stamp for count freshness

---

### SP2 — Hero trust strip: speed-to-draft claim
**Placement:** Hero trust strip (slot 2)

**Strong proof copy:**
- "From keyword brief to publish-ready draft in **{{median_minutes}} minutes** (median)."

**Pending validation copy:**
- "Go from keyword brief to a strong first draft in one focused session."

**Evidence required:**
- Event timestamps: brief created → draft generated
- Median calculation method and sample window

---

### SP3 — Mid-page testimonial: quality of first draft
**Placement:** Testimonial block after "How it works"

**Strong proof copy:**
- "\"TuxSEO gave us drafts worth editing, not rewriting. We publish more consistently now.\" — {{name}}, {{role}} at {{company}}"

**Pending validation copy:**
- "\"The draft quality surprised us — we started from structure, not a blank page.\" — Customer quote pending approval"

**Evidence required:**
- Written customer quote approval
- Name/title/company attribution consent
- Optional source link (case note or customer message)

---

### SP4 — Mini case card: consistency gain
**Placement:** Mini case studies section before pricing

**Strong proof copy:**
- "**Before:** {{before_posts_per_month}} post/month
**After:** {{after_posts_per_month}} posts/month in {{time_window}}
**Why:** TuxSEO standardized brief → draft → review."

**Pending validation copy:**
- "Teams report improved publishing consistency after adopting a repeatable brief-to-draft workflow."

**Evidence required:**
- Publication logs (CMS timestamps)
- Baseline vs after period definition
- Short method note (what changed operationally)
Comment on lines +70 to +73
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟡 Minor

Tighten the wording on the baseline/after period bullet.

Baseline vs after period definition is awkward and matches the grammar warning here. A small rewrite like Baseline and after-period definition reads more cleanly. As per coding guidelines, docs/**/*.{md,mdx} should "write documentation that is easy to scan and navigate."

🧰 Tools
🪛 LanguageTool

[grammar] ~72-~72: Use a hyphen to join words.
Context: ...ogs (CMS timestamps) - Baseline vs after period definition - Short method note (w...

(QB_NEW_EN_HYPHEN)

🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@docs/content/features/landing-page-social-proof-pack-from-old.md` around
lines 70 - 73, Replace the awkward bullet text "Baseline vs after period
definition" with a clearer phrase such as "Baseline and after-period definition"
in the list under the Evidence required section; locate the exact string
"Baseline vs after period definition" in
docs/content/features/landing-page-social-proof-pack-from-old.md and update it
to the new wording so the docs are easier to scan and follow.


---

### SP5 — Mini case card: ranking traction
**Placement:** Mini case studies section before pricing

**Strong proof copy:**
- "Tracked pages reached **{{top_10_keywords_count}} top-10 rankings** across {{time_window}} after consistent publishing."

**Pending validation copy:**
- "Customers use TuxSEO to execute keyword-focused publishing that supports ranking traction over time."

**Evidence required:**
- Search Console / SEO tool export (query + page)
- Date range and inclusion criteria
- Confirmation that gains are tied to pages created via TuxSEO workflow

---

### SP6 — Pricing vicinity reassurance: keeps editorial control
**Placement:** Immediately above pricing table or near pricing CTA

**Strong proof copy:**
- "Your team keeps final edit and publish control — TuxSEO handles the heavy first-draft lift."

**Pending validation copy:**
- "Built for teams that want AI speed without giving up editorial control."

**Evidence required:**
- Product flow screenshot(s): review/edit/publish steps
- Confirmation in product docs that publishing requires user action/approval

---

### SP7 — CTA vicinity friction reducer: WordPress workflow proof
**Placement:** Final CTA vicinity (just above or below CTA)

**Strong proof copy:**
- "Connect WordPress, generate a draft, review, and publish from your existing workflow."

**Pending validation copy:**
- "WordPress publishing workflow available (draft-first flow)."

**Evidence required:**
- Integration setup doc + product screenshots
- QA verification that flow works on current release

---

### SP8 — FAQ trust answer: objection handling on generic AI output
**Placement:** FAQ section above final CTA

**Strong proof copy (FAQ answer excerpt):**
- "No — output is grounded in your project context, target keywords, and content brief. Teams use TuxSEO as an expert first draft they can refine quickly."

**Pending validation copy:**
- "We design outputs around your brief and workflow so editing focuses on quality, not starting from zero."

**Evidence required:**
- Prompt/context architecture description
- Before/after editing examples from real usage

---

## 2) Evidence matrix (what exists vs what must be collected)

| Proof ID | Claim type | Current confidence | Evidence status | Source requirement | Owner | Publish gate |
|---|---|---:|---|---|---|---|
| SP1 | Active projects count | Pending | Needs refreshable metric query | Analytics/DB query + definition of "active" + timestamp | Product/Ops | Must verify before numeric publish |
| SP2 | Speed-to-draft median | Pending | Not yet calculated | Event logs + median method + sample size | Product/Eng | Must verify before numeric publish |
| SP3 | Testimonial quote | Pending | Quote exists conceptually, no formal approval attached | Written permission + attribution approval | CS/Founder | Attribution required |
| SP4 | Publishing consistency improvement | Pending | Needs case-level baseline/after data | CMS export + period comparison | CS/Content | Numeric only after validation |
| SP5 | Ranking traction | Pending | Needs SEO export and attribution notes | GSC/export + page mapping | SEO/Ops | Numeric only after validation |
| SP6 | Editorial control claim | Strong | Product workflow supports this | UI screenshots + docs | Product | Safe to publish now |
| SP7 | WordPress workflow claim | Strong (if current integration passes QA) | Setup guide exists; QA check needed for current release | Setup doc + current QA run | Product/Eng | Publish after quick QA pass |
| SP8 | Non-generic output claim | Pending | Conceptual evidence only | Prompt/context architecture + editing examples | Product/Content | Avoid over-claiming until examples are documented |
Comment on lines +138 to +149
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

Move the evidence matrix and handoff rules out of the feature doc.

Owner, Publish gate, proof_registry, approval records, and verification rules are internal process details. They make sense in an ops/handoff artifact, but they make this page read like an implementation brief instead of feature documentation. As per coding guidelines, docs/**/*.{md,mdx} should "write documentation focused on what users can do with features, not implementation details, using plain language without technical jargon."

Also applies to: 174-184

🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@docs/content/features/landing-page-social-proof-pack-from-old.md` around
lines 138 - 149, The evidence matrix and handoff rules are internal ops details
and should be removed from this feature doc; extract the entire table (rows
SP1–SP8) plus any references to Owner, Publish gate, proof_registry, approval
records, and verification rules and move them into an internal handoff/ops
artifact, leaving the feature page with a concise, user-facing summary of what
proofs or social-proof types exist (one-line descriptions per proof ID if
needed) without operational columns or jargon; update any in-doc references at
lines ~174-184 to point to the new internal artifact instead of embedding the
table here.


## 3) Final on-page placement recommendation

### A. Hero (high visibility, low cognitive load)
1. **Primary headline + CTA**
2. **Trust strip (SP1 + SP2)**
- If metrics not validated, use pending variants.

### B. Mid-page credibility layer
3. **How it works**
4. **Testimonial block (SP3)**
- Keep to 1–2 short quotes max; include attribution when approved.

### C. Conversion support before pricing decision
5. **Mini case cards (SP4 + SP5)**
- Show one consistency case and one ranking traction case.
6. **Pricing section with reassurance line (SP6)**
- Place directly near price to reduce "AI takeover" anxiety.

### D. Final conversion zone
7. **Final CTA with workflow proof (SP7)**
8. **FAQ objection answer (SP8)**
- Place FAQ directly above final CTA to resolve last-mile hesitation.

## 4) Implementation notes for handoff

- Add every claim to a `proof_registry` doc with:
- snippet ID
- live copy in production
- evidence URL/file
- last verified date
- approval owner
- Never publish unverified numbers. Use non-numeric pending variants until evidence is locked.
- For testimonials/logos, require explicit permission records.

## 5) Ready-to-implement deliverables checklist

- [x] 8 social proof snippets provided (>=6 required)
- [x] Each snippet has strong + pending variants
- [x] Each snippet mapped to evidence/source requirements
- [x] Evidence matrix provided (exists vs must collect)
- [x] Final placement plan provided (hero, pricing, CTA vicinity, FAQ)
- [x] Copy is implementation-ready with placeholders where validation is pending
Loading