wvvb/website-coprighting

Webサイトコピーライティング

Webサイトは、適切な人物が自分の状況を認識し、製品の内容を理解し、次に何をすべきかを知ることができるようにする必要があります。

原則: 製品の機能リストから外側に向かって書くのではなく、訪問者の現実から外側に向かって書きます。コピーは、マーケティングの仕組みを説明するマーケターのように聞こえるのではなく、その仕事を理解している人のように聞こえる必要があります。

これは、文章作成と情報設計のスキルであり、AI検出ツールでも、堅苦しいコンバージョンフォーミュラでもありません。真実性、アクセシビリティ、正確性を犠牲にして「人間らしく」聞こえるように最適化しないでください。

エビデンスラベル

バージョン1.1. ラベルは、有効性に関する主張にのみ表示されます。つまり、認識、理解、信頼、またはコンバージョンを向上させるという主張です。義務やワークフローのステップは評価の対象外です。

• [E] 検証済みの直接的なエビデンス: 記載された効果を測定した査読付き研究または文書化されたテストで、効果量と限界が示されているもの。
• [P] 妥当なプラクティス: このオーディエンスに対する直接的な測定されたエビデンスがなくても有用なもの。
• [S] 編集スタイルの好み。スタイル項目は references/evidence.md で評価されています。このスキル内でインラインでタグ付けされることはありません。

このスキルのいかなるルールも、ランディングページのコンバージョンに対して [E] ではありません。コンバージョンに関するアドバイスは、実際のサイトでテストすべき仮説として扱い、測定なしに改善を約束しないでください。ラベルのない有効性主張は、ここでは [P] のアドバイスプラクティスです。義務とワークフローステップは評価対象外です。完全な項目別分類、出典、および候補実験は references/evidence.md にあります。

譲れないルール

1. 関連性でリードする。 対象とする訪問者が認識する特定の問題、タスク、または成果を具体的に挙げます。訪問者が何を提供されているかを理解できる程度に、製品についてすぐに説明します。 [P]
2. 因果関係を説明する。 製品が実際に何をして助けるのかを示します。メカニズムを約束に置き換えないでください。 [P]
3. 自然に聞こえるようにする。 日常的な言葉、具体的な名詞、通常の動詞を好みます。技術的なオーディエンスに対しては、技術的な正確性を維持します。
4. 提案するWebサイトのコピーにemダッシュやenダッシュを使用しない。 それらをピリオド、カンマ、コロン、または自然な言い回しに置き換えます。ソースマテリアルを引用する場合は、元の句読点を保持します。ユーザーが明示的に別のスタイルを要求した場合は、それに従います。
5. 作為的な感情を作り出さない。 痛み、緊急性、恐怖、統計、社会的証明、結果、機能をでっち上げないでください。
6. 強制的なテンプレートは使わない。 すべてのWebサイトに同じ問題 / 動揺 / 解決策 / 機能 / お客様の声 / CTA のシーケンスを与えないでください。訪問者が決定するために必要なものに基づいてセクションを選択します。
7. 単に書き換えるためだけに書き換えない。 オリジナルの方が明確であれば、それを維持します。理解を向上させる最小限の変更を行います。

訪問者が何を理解する必要があるかを判断する

編集する前に、ユーザーが提供する資料（ライブページ、スクリーンショット、現在のコピー、概要、またはソースコード）を検査します。以下を判断します。

• オーディエンス: 誰がこれを必要としているか？「全員」ではなく、認識可能な役割や状況を使用します。
• トリガー: 今まさに助けを求めさせる出来事は何か？
• ジョブ: 彼らは何を達成しようとしているか？
• 障害: 現在のアプローチが失敗する、または手間がかかりすぎる理由は何か？
• コスト: 障害が彼らにとって実際に何を意味するか？失われた時間、未回答の質問、混乱、リスク、またはお金。コンテキストによって裏付けられた結果のみを含めます。
• 望ましい変化: 彼らの次の1時間、1日、またはワークフローをより良くするものは何か？
• 製品メカニズム: 製品は具体的にどのようにその変化を引き起こすか？
• エビデンス: 実証、文書化、または検証されていることは何か？
• アクション: 彼らが実際にクリック、試す、リクエスト、または次に読むことができるものは何か？

事実と仮定を明確に区別します。詳細が不足している場合は、控えめな言葉を使用し、ユーザーへの説明で仮定にラベルを付けます。特定の顧客やワークフローをでっち上げないでください。

内部問題モデルを構築する

これを推論の補助として使用し、公開するテキストとしては決して使用しないでください。

[現実の状況] にいる誰かが [ジョブ] をしようとしているが、[障害] がある。彼らは [成果] を望んでいる。製品は [具体的なメカニズム] によって助ける。

次に、それを認識可能な瞬間に凝縮します。その瞬間は、抽象的なカテゴリーよりも重要です。

• 抽象的: 「財務チームは、合理化された調整ワークフローを必要としています。」
• 具体的: 「支払総額と取引記録が一致しません。」
• 抽象的: 「分散デプロイ全体の可観測性を向上させます。」
• 具体的: 「デプロイに失敗しました。エラーを見つけるために3つのサービスを検索しています。」

優れた見出しは、問題 または 望ましい成果から始めることができます。対象とする訪問者に「これは私のためのものだ」と最も早く伝わる方を選択します。オーディエンスが自分が何を望んでいるかを正確にすでに知っている場合、問題ファーストの見出しが自動的に最善とは限りません。

メッセージを構成する

これらのビートを内部的に考えてください。それらを6つの同一のWebサイトセクションとして印刷しないでください。

1. 認識: 訪問者が経験した、または想像できる実際の状況。
2. 重要性: 未解決、困難、高額、または不確かなままのもの。特定の結果1つで十分なことが多い。
3. 救済: 可能になること、または簡単になること。
4. メカニズム: 製品がどのように訪問者をそこに導くか。
5. 信頼性: 信頼を獲得する実際の例、デモ、機能、制限、または出典。
6. 次のアクション: その宛先が約束を果たすCTA。

最初の画面は通常、訪問者がスクロールしなくても、認識、解決策、および信頼できるメカニズムを提供する必要があります。訪問者がすでに理解している問題をドラマチックに描くのに半ページを費やさないでください。

ヒーローを書く

• 見出し: 訪問者のジョブ、問題、または望ましい成果に関する1つの明確な考え。具体的であることは、賢いことより優れています。
• サポート: 誰を助けるかを示し、それがどのように機能するかを1つか2つの自然な文で説明します。読者の理解を変えない単語はすべて削除します。
• CTA: 「例を見る」、「ドキュメントを読む」、「デモを試す」、「メンテナーに相談する」などの実際のアクション。ただし、そのアクションが存在する場合に限ります。
• ビジュアル: 存在する場合、または要求された場合、抽象的な装飾的な比喩よりも、実際のワークフロー、インターフェースの状態、またはbefore/afterのデータ例を優先します。

見出しとサポートは異なる役割を果たす必要があります。同じ約束を異なる言葉で3回言わないでください。

解決策をスローガンではなく原因として説明する

重要な機能ごとに、次のように推論します。

何をするか -> 訪問者にとって何が変わるか -> なぜそれが重要なのか -> 何が主張を裏付けるのか。

例：

• 機能: 生成されたSQLを顧客のインフラ上でParquet、JSON、CSVに対して実行する。
• 何が変わるか: 顧客は、コンテンツをホスト型分析プロバイダーに送信せずに、それらのファイルを調査できる。
• 意味: 彼らのデータは、彼らが運営するインフラ内に留まる。
• 範囲: これは、システム全体にセキュリティリスクがないことを証明するものではない。

このチェーンの最も関連性の高い部分をヒーローで使用します。残りは、必要に応じてデモ、ワークフローセクション、FAQ、またはドキュメントに配置します。

コピーを人が書いたように感じさせる

人間らしく聞こえるコピーは、多くの場合、より具体的で、対称性が低く、自己説明しようとする熱意が少ないものです。それは、1回のパスで生成されたのではなく、編集されたように感じられます。

優先するもの

• カテゴリーラベルではなく、具体的な状況。
• 概念的な専門用語ではなく、聞き慣れた言い回し。
• このオーディエンスと製品にのみ意味のある詳細。
• 空虚な興奮ではなく、直接的な説明。
• 読者がアイデアを追うのに役立つ場合の、異なる文のリズム。
• 主張を明確にする役立つ例。
• 正直な限界、実際的なトレードオフ、および信頼を築く場合の正確な技術用語。
• 作り付けの接続フレーズではなく、実際のアイデアに従う自然な遷移。

削除または書き換えるもの

• マーケティングの埋め草: 「解き放つ」、「強化する」、「シームレス」、「最先端」、「ゲームチェンジャー」、「次世代」、「革命を起こす」、「エンパワーする」など、意味を置き換える場合。
• 偽の対比: 「それは単なるXではありません。それはYです。」「Xをやめて、Yを始めましょう。」「Xの未来がここにあります。」実際の違いを通常の言葉で説明する場合にのみ、対比を使用します。
• 構造のアナウンス: 「このセクションでは、...を探求します。」「さあ、始めましょう。」「これが重要な理由は次のとおりです。」これから説明しようとしていることを訪問者に伝えないでください。説明してください。
• 繰り返しの言い換え: すべて同じ主張をする見出し、サブタイトル、3つの機能カード、および閉じの段落。
• 完全に対称的なセクション: 同一の文法パターン、同一の単語数、およびレイアウトを完成させるためだけの整然とした要約を持つ3つのカード。
• 過剰に説明された意味: 「これにより、企業は成功をコントロールできるようになります。」結果が明らかな場合は、書くのをやめてください。
• 空虚な感情的な言葉: 具体的な理由なしに「頭痛の種に別れを告げる」や「もう二度と心配しない」。
• 無理に作った会話のテクニック: 繰り返される修辞的な質問、偽の逸話、無理なユーモア、過度な短縮形、および人工的な弱さ。
• 不自然に聞こえる構文的な装飾: 密集した名詞句、形容詞の連なり、および明確な文の代わりをする句読点。

単語のブラックリストを作成して編集戦略にしないでください。 単語は適切な文脈では適切であり得ます。上記の句読点に関する要件はプロジェクトのスタイルルールです。より深いタスクは、思考、構造、およびエビデンスを修正することです。ダッシュを削除し、「レバレッジ」を「使用」に置き換えただけのコピーライターは、問題を解決していません。

2つのレベルで編集する

構造的パス:

• 読者の実際の問題が見えているか、それともページが自分自身について話しているか？
• 各セクションは新しいことを教えているか、実際の反論を取り除いているか？
• 訪問者が興味を失う前に製品が登場するか？
• 議論が、モデルがテンプレートにデフォルトしたためだけに直線的になっていないか？
• 不要な要約、繰り返しの段階ラベル、または誇張された新旧の物語はないか？
• コンテンツは、一般的なセールスファネルではなく、この特定の訪問者がどのように決定するかに従っているか？

文レベル:

• 知識のある人が実際にこの文を別の人に言うだろうか？
• より具体的な名詞や動詞はないか？
• 事実を削除せずに文を削除できるか？
• 文は、何かを説明する代わりに印象的に聞こえようとしていないか？
• 事実は正確で、利点は裏付け可能か？
• 提案されたコピーにemダッシュやenダッシュはないか？削除する。

訪問者として結果を読み、書き手として読まないでください。リハーサルされたピッチのように聞こえる場合は、「人間らしくする」トリックを追加するのではなく、思考を単純化します。

心理学を責任を持って使用する

心理学的に有用な原則を、人を操作するための言い訳としてではなく、診断レンズとして使用します。以下の各原則は [P] です。

• 認識: 人々は、説明されている状況を特定できるときに関与します。 [P]
• 認知的な容易さ: 具体的な言語と一貫性のあるパスは、労力を減らします。 [P]
• 情報の匂い: 見出しとCTAは、次に何が来るかを正確に予測する必要があります。 [P]
• コントロール: 人々は、何を検査、変更、保持、または元に戻せるかを知りたがります。 [P]
• 信頼: エビデンス、実際のメカニズム、および認められた限界は、大げさな主張よりも有用であり得ます。 [P]
• 動機: コピーは、訪問者が達成したい何かに接続する必要があり、不安や圧力を発明してはいけません。 [P]

偽の希少性、社会的証明、でっち上げたコスト削減、裏付けのないパフォーマンス比較、操作的なデフォルト、または暗黙の保証を避けてください。

ページアーキテクチャは状況による

開発者CLI、財務運用製品、消費者向けユーティリティに同じランディングページを作成しないでください。

エキスパートまたは開発者向けオーディエンスの場合: 通常は、実際のタスクまたは技術的な成果でリードします。コマンド、インターフェース、例、アーキテクチャの詳細、またはドキュメントへのリンクを早い段階で表示します。よく知られている問題を過剰に説明することは避けてください。

運用バイヤーの場合: 認識可能なインシデントまたは責任でリードします。彼らが調査、防止、または完了できることを説明し、次にワークフローと制約を示します。

馴染みのないカテゴリーの場合: 製品を早い段階で定義し、既知の状況に固定し、誰かが実際にどのように使用するかを示します。新規性だけでは価値提案になりません。

単一機能または既に明確なページの場合: 正確な変更を行います。長い問題ストーリーを後付けで追加しないでください。

すべてのセクションは、実際の質問や反論に答えることでその場所を獲得しなければなりません。そうでなければ、削除します。

例：Queryance

弱い、機能ファーストのバージョン

金融運用のためのオープンソース分析。自然言語をSQLに変換し、お客様のインフラ上のParquet、JSON、CSVファイルに対して実行します。

これは最初にメカニズムを説明しています。訪問者が気にする理由を考えさせることになります。

人間の問題バージョン

支払額が一致しない理由を調べてください。

Queryanceは、SaaSの財務チームが記録間の差異を調査するのに役立ちます。質問をし、SQLを確認し、お客様自身のインフラ上のParquet、JSON、またはCSVファイルに対して実行します。

CTA: メンテナーに相談する

最初の文は実際のジョブを挙げています。2番目の文は、製品が誰のためのものか、どのように機能するかを説明しています。CTAは、メンテナーに連絡する方法が実際に存在する場合にのみ適切です。

やりすぎなバージョン

それでも金融の混乱に溺れていますか？

時代遅れのスプレッドシートに費やす時間をやめましょう。次世代のインテリジェントな金融運用で、楽々とした調整を解き放ちましょう。

これは感情を発明し、業界の決まり文句に頼り、メカニズムを決して説明していません。良いバージョンよりも短いですが、情報量は劣ります。

これらの例は出発点であり、必須のパターンではありません。実際の顧客が異なる言葉を使用している場合は、彼らの言葉の意味を確認した上で、その言葉を優先してください。

実行モード

ユーザーのリクエストの範囲に従います。

監査

上位3〜5つの具体的なコピーまたは階層の問題を提供します。関連するテキストを引用し、訪問者が誤解したり見逃したりする内容を説明し、対象を絞った修正を推奨します。すでに機能している部分を特定します。測定なしにコンバージョンの改善を主張しないでください。

リライト

リクエストされたセクションに対して、サイトの既存のブランドボイスを使用して、本番環境で使用できるコピーを提供します。

…[翻訳のために切り詰め]