unslop-seo

SEOと回答エンジン向けの不要な文章を取り除く

AIで編集された記事には、2つの問題があります。エンジニアは水増し表現を見抜いて離脱し、直接的な回答は前置きの200語に埋もれて回答エンジンに引用されません。このスキルでは、MDX、Markdown、TSX、またはHTMLファイルを3つのフェーズに沿って順番に直接編集します。事実を確認し、構成を整え、不要な文章を削ります。事実の確認が最初なのは、後で削除する文章を書き直す時間を無駄にしないためです。

対象ファイルを選ぶ

Did the user name files or URLs?
├── Yes -> edit exactly those
└── No -> run `git diff --name-only HEAD~5 -- '*.md' '*.mdx' '*.tsx' '*.html'`
    ├── Content files changed -> edit those
    └── None -> list `content/blog/`, `app/**/page.tsx`, `docs/` and edit the 3 newest posts

ファイルごとの判断ツリー

Phase 1: Does every product claim name a mechanism or a number?
├── Check `seo/kb/brand-ssot.md`, `/pricing`, `/about`, or source code
├── Feeling words ("blazing-fast", "seamless") -> exact mechanics ("compiles 1,200 MDX routes in 1.4s")
└── Sentence could appear unchanged on a competitor's site -> delete or rewrite
Phase 2: Is the page built for featured snippets and answer-engine chunking?
├── Does the first 40 words hold the direct answer (and the top pick's link on listicles)?
├── Every page: sentence-case headings, 1 or more `<h2>` phrased as a buyer question?
├── Long-form (1,200+ words): 5 or more `<h2>`?
└── Comparison items: same self-contained block each (verdict, best for, trade-offs, price)?
Phase 3: Does any line hit the 20-point slop table?
├── Rewrite until the check script below prints 0 hits
└── Then read the file once for rows 9, 11-13, 15, 16, 19, 20 (the script cannot see them)

フェーズ1：エンティティと事実の確認

文章に手を入れる前に、seo/kb/brand-ssot.md（存在する場合）、/pricing、/about、またはソースコードを確認し、製品の機能を把握します。確認できなかった数値は絶対に追加せず、代わりに [NEEDS FACT: <what>] と記載し、作業記録にも記載します。マージ時にファイルがデプロイされる場合は、マーカーをコメントに入れ（MDXでは {/* [NEEDS FACT: ...] */}、MarkdownまたはHTMLでは ``）、未確認の主張を文章から削除します。理由：公開中のページにマーカーが表示されると壊れているように見えます。また、未確認の主張はどちらにしても公開してはいけません。

1. 印象より仕組みを示す。 "the database stays close at hand"、"effortless developer experience"、"enterprise-grade reliability" は印象を表しています。それぞれを仕組みまたは測定済みの数値に置き換えます。エンジニアや回答エンジンが引用するのは事実であり、形容詞ではありません。
   • 変更前: "DeployFast offers a blazing-fast, seamless preview workflow that keeps your team in flow."
   • 変更後: "DeployFast builds Next.js preview containers in 11 seconds on a dedicated NVMe runner and posts the live URL and Lighthouse diff to your GitHub PR."
2. 競合製品への置き換えテスト。 段落ごとに、競合他社のサイトにそのまま掲載できるかを確認します。できる場合は削除するか、ファイルパス、CLI フラグ、API フィールド、または価格を軸に書き直します。
3. 情報源を明記するか、出典への言及を削除する。 "Experts believe"、"Industry reports suggest"、"Many teams find" と書いてはいけません。仕組みを直接述べるか、情報の出どころとなった一次データにリンクします。

フェーズ2：回答エンジン向けの構成

ChatGPT、Perplexity、Claude、Google AI Overviews は、ページを見出しで区切られたチャンクに分割し、それだけで回答になるチャンクを引用します。各セクションを単独で抜き出して使えるように構成します。

1. 最初の40語で回答する

最初の40語以内に直接的な回答を記載します。リスト記事やまとめ記事では、同じ段落内で最有力の選択肢の名前を挙げ、リンクします。"In today's fast-paced digital world..." のような前置きがあると、引用される範囲に回答が収まりません。

• 変更前: "When building a SaaS application with Stripe, managing invoices and tax compliance across multiple jurisdictions can quickly become a headache for small engineering teams. In this guide, we will explore several options."
• 変更後: "[InvoiceKit](https://invoicekit.io) generates VAT-compliant Stripe PDFs in 45ms from a single webhook and costs $19/month flat for unlimited invoices. Below we compare 6 Stripe invoice generators on webhook latency, multi-currency support, and per-invoice fees."

2. 見出し

• 1,200語以上の長文ガイドや比較記事には、5つ以上の <h2> を設けます。レベルを飛ばしてはいけません（<h1> の次にいきなり <h3> を置かないでください）。
• 1つ以上の <h2> を、購入者が入力する質問そのものにします（## How much does Postgres logical replication lag under write bursts?）。
• 質問形式の <h2> の直後には、コードや表より前に、1～2文の直接的な回答を置きます。この質問と回答の組み合わせが、強調スニペットやLLMに引用されます。
• すべての見出しをセンテンスケースにします（## How to configure webhook retries）。

3. 自己完結した比較ブロック

製品を比較するページでは、各項目に同一形式のブロックを用意します。比較の途中で分割するチャンク処理によって、競合製品の価格や機能の欠如が自社ブランドの情報として扱われることがあります。自己完結したブロックには、製品名、評価、価格をそれぞれ含めます。

### 1. InvoiceKit (best for flat-rate Stripe PDF and VAT automation)

**Verdict:** Generates localized VAT/GST PDFs from Stripe webhooks in `45ms` with no percentage cut of revenue.

- **Best for:** SaaS teams sending `500+` Stripe invoices a month who want to avoid `0.4% to 0.8%` billing fees.
- **Strengths:** Native `invoice.finalized` webhook handler, EU VIES VAT ID validation, custom HTML/CSS templates.
- **Trade-offs:** Stripe-native only; Paddle and Polar need the REST endpoint.
- **Pricing:** Free up to 50 invoices/month; `$19/month` flat for unlimited.

フェーズ 3：20 項目の冗長表現チェック

ファイル内の該当箇所をすべて修正します。

#	パターン	ルールと理由
1	全角ダッシュ（U+2014）と半角ダッシュ（U+2013）	ファイル内での使用をゼロにします。ピリオド、カンマ、コロンを使います。LLM が書いた文章に最もよく見られる句読点です。代わりにスペースで囲んだハイフン（-）を使っても、同じ印象になります。数値の範囲には通常のハイフン（3-5）を使います。
2	"Not just X, but Y" / "It's not X, it's Y"	否定を使った枠組みを削除し、Y を述べます。対比の枠組みは余分な修辞です。
3	AI らしい語彙	delve、pivotal、tapestry、landscape、testament、underscore、foster、garner、interplay、intricate、crucial、vibrant、enduring、showcase、additionally、moreover、furthermore を削除します。平易な語に置き換えるか、何も加えません。
4	抽象的な比喩表現の名詞	substrate → base、vector → method、locus → spot、nexus → center、surface → API／page、bedrock → foundation、paradigm → model、north star → goal、flywheel → loop。具体的な名詞を使えば、疑似技術的な曖昧さを避けられます。
5	気取った is／has	serves as、stands as、boasts、features、offers a を is、has、または能動態の動詞に置き換えます。
6	誇大表現	groundbreaking、revolutionary、game-changing、seamless、blazing-fast、world-class、cutting-edge、next-generation、robust を削除します。代わりに数値や仕組みを示します。
7	文末の -ing 節	"...highlighting its efficiency"、"...ensuring scalability" のような表現を削除します。末尾に事実が含まれる場合は、独立した文にします。
8	大げさな動詞や表現	utilize／leverage → use、facilitate → help、commence → start、numerous → many、in order to → to、due to the fact that → because、in the event that → if。
9	受動態	行為者を明示します（"queries are validated" ではなく "the compiler validates queries"）。受動態ではソフトウェアの仕組みが見えにくくなります。
10	副詞	"runs quickly"、"significantly reduces"、"easily integrates" を、変化量（"cuts build time by 38%"）またはより具体的な動詞に置き換えます。
11	箇条書きラベルの繰り返し	"**Performance:** Performance is improved by..." を "**Sub-2ms cold starts.** Workers boot from pre-warmed V8 snapshots." に置き換えます。ラベルには、文で繰り返されない情報を含めます。
12	水増しされた 3 項目の列挙	"speed, reliability, and innovation" に実質的な項目が 2 つしかない場合は、2 つだけ列挙します。
13	類義語の使い回し	名詞を 1 つ（the CLI など）に決めて繰り返し使います。呼び名を変えると、読者は別々のツールが 4 つあると思ってしまいます。
14	実態のない範囲表現	X と Y が実際の尺度上の両端でない場合は、"from startups to Fortune 500" を削除し、具体的な対象を列挙します。
15	コロンによる文の接続	コロンは、リスト、コードブロック、または例の導入にのみ使います。独立した文を 2 つつなぐ場合は、ピリオドを使います。
16	タイトルケースと絵文字の見出し	<h2>／<h3> は文頭のみ大文字にします。見出しや箇条書きから装飾用の絵文字を削除します。
17	スマートクォート（U+201C、U+201D、U+2018、U+2019）	MDX やコードサンプルが正しくコンパイルされ、きれいにコピーできるよう、ASCII の直線型引用符を使います。
18	チャットボット特有の表現	"In this article, we'll explore"、"Let's dive in!"、"I hope this helps"、"As we have seen" を削除します。
19	定型的なつなぎの表現	"Despite these challenges, X continues to..." や "While X has its pros and cons..." を削除し、トレードオフを具体的に述べます。
20	単調な文のリズム	30 語を超える文は分割します。短い 6 語の文と、説明を加える 15～20 語の文を交互に並べ、実務者らしいリズムにします。

チェックスクリプト（編集前と編集後に実行）

対象ファイルに対して実行します。該当する行をすべて表示し、残っている場合はゼロ以外の終了コードで終了します。フェンスで囲まれたコードブロックはスキップするため、サンプル内のコマンドや YAML は対象になりません。

python3 - <target-files> <<'PY'
import re, sys
pat = re.compile(
    r"[\u2013\u2014\u201c\u201d\u2018\u2019]"
    r"|(?<=[A-Za-z0-9,)]) - (?=[A-Za-z0-9(])"
    r"|\bnot (just|only) [^.]{1,60}?(\bbut\b|[,;] it'?s\b)|\bit'?s not [^.,]{1,40}, it'?s\b"
    r"|\b(delve\w*|pivotal|tapestry|landscape|testament|underscor\w*|foster\w*|garner\w*"
    r"|interplay|intricate|crucial|vibrant|showcas\w*|utiliz\w*|leverag\w*|seamless\w*"
    r"|paradigm|bedrock|substrate|north star|flywheel|nexus|locus"
    r"|blazing-fast|groundbreaking|game-changing|cutting-edge|revolutionary|world-class|next-generation|robust"
    r"|serves as|stands as|boasts|in order to|due to the fact that|facilitat\w*|commenc\w*"
    r"|significantly|easily|experts (believe|say|agree)|industry reports|studies show|many teams find"
    r"|from startups to|in this (article|guide|post)|let'?s dive|i hope this helps|as we have seen|in conclusion"
    r"|in today'?s fast-paced|moreover|furthermore|additionally)\b",
    re.I,
)
hits = 0
for f in sys.argv[1:]:
    fence = False
    for i, line in enumerate(open(f, encoding="utf-8"), 1):
        if line.lstrip().startswith(("```", "~~~")):
            fence = not fence
            continue
        if not fence and pat.search(line):
            hits += 1
            print(f"{f}:{i}: {line.strip()[:160]}")
print(f"{hits} hits")
sys.exit(1 if hits else 0)
PY

該当数が 0 であることは必須ですが、それだけでは十分ではありません。このスクリプトは、1〜8、10、14、17、18 行目と、19 行目の一部を対象としています。受動態、ラベルの言い換え、冗長な三項表現、類義語の反復、コロンでの文の接続、タイトルケース、文のリズムについては、判断ツリーに従って読み直してください。理由：すべての文が依然として一般的な内容でも、正規表現チェックに合格する場合があるためです。

出力

ファイルをディスク上で編集してください。保存せずに、書き直した全文をチャットに貼り付けることは絶対にしないでください。チェック用スクリプトで 0 hits が表示されたら、ファイルごとに次の確認文を返信してください。

### Unslop pass: `<file-path>`

- **First 40 words:** now lead with `[direct answer + metric/link]`.
- **Headings (`X` H2s):** `N` converted to sentence case; added `## [buyer question?]`.
- **Grounding:** replaced `N` vague claims (`[example]`, `[example]`); open `[NEEDS FACT]` markers: `N`.
- **Slop:** removed `X` dashes, `Y` AI-vocabulary terms, `Z` passive or filler clauses. Check script: 0 hits.

ページが公開されたら、質問形式の見出しを AI SEO Tracker（MCP：https://aiseotracker.com/api/agent/mcp）にプロンプトとして追加し、ChatGPT、Perplexity、Gemini、Google AI Overviews が、書き直したセクションから実際にどのスニペットを引用しているか確認してください。