コンテンツプルーニングは、検索最適化のなかで最も直感に反する作業です。ページが増えれば流入も増えるはずだ、という感覚が誰の頭にもあるからです。記事を公開する行為は資産が積み上がっていくように感じられます。ところが記事を消す行為は、誰かが費用を払って作らせた仕事をそのまま捨てているように感じられます。だからこそ、削除は最後まで先送りにされ、増え続けるページの山だけが残ります。 削除が効く仕組みは単純で、自分のサイトのページ同士が競合しているという一点に尽きます。自分のページのうち二本が同じ検索意図を狙っていると、本来なら一本に集まっていたはずの評価が二つに割れます。そして、どちらを見せるかを判断しなければならない検索側の仕組みが、結果...
ウェブ開発チュートリアル
HTML CSS JavaScript パフォーマンス アクセシビリティ SEO を扱う分かりやすいチュートリアル。レスポンシブレイアウトや最新ツール、サイト最適化も学べます。
エンティティSEOは、多くの最適化アドバイスが今も見落としている一つの事実から始まります。検索エンジンはずっと以前に文字列の照合をやめました。いま照合しているのは「モノ」です。ページはある語句を含んでいるかどうかで評価されるのではなく、その語句の背後にある概念について書かれたページだとシステムが信じているかどうか、そしてその概念が何であるかについてシステムがどれだけ確信を持てているかで評価されます。 この区別が、キーワードの繰り返しが効くのか、それともまったく何も動かさないのかを決めます。文字列を照合するシステムでは、繰り返しはシグナルでした。エンティティを照合するシステムでは、繰り返しは単なるノイズです。実際に順位や引用を動かすの...
順位は取れているのに引用されない。検索エンジン最適化を正しく実行しているのに、それが何も生まないという、非常に特有の苛立ちがこれです。順位は上がります。表示回数も伸びます。それなのにクリックは後に続かず、タイトルタグを何度書き直しても状況は変わりません。 これはあなたの最適化の失敗ではありません。検索結果ページがリンクの一覧であることをやめ、ひとつの回答になったときに起きることです。そしていまや、これは診断に値する異常ではなく、ごく普通の状態になりました。 Search Consoleから取得した、2026年8月上旬までの28日間の自社実測値： このサイトでは531件のクエリが上位十位以内に入り、28,847回の表示に対してクリック...
llms.txt は今のところ何かの役に立っているのか。その問いに対する正直な答えはこうです。測定できる範囲ではほとんど何の役にも立っておらず、このファイルが AI 上での可視性に不可欠だと言ってくる人は、たいてい何かを売ろうとしています。それでいて「一つ用意しておいたほうがよい」と勧めるのは、かなり落ち着かない立場です。ですからこの記事では、まず数字を並べ、そのうえで推奨の理由を順に説明していきます。 ファイルそのものは筋の通ったアイデアです。サイトのルートに置くマークダウン形式の索引で、robots.txt がクローラーに「何を取得してよいか」を伝えるのと同じように、言語モデルに「何を公開していて、それがどこにあるか」を伝えま...
AIクローラーを遮断すべきかどうかは、技術の問題として持ち出されることがほとんどです。しかし技術の問題ではありません。遮断そのものは設定を数行書くだけの作業で、robots.txt に記述を足すか、ネットワーク側でルールを一つ有効にするか、いずれにしても十分もあれば終わります。難しいのは、自分がそれを本当に望んでいるのかを決めるところであり、その判断は完全に商売の判断です。自社のコンテンツが学習に使われないよう守るのか、それとも人々が検索結果の一覧の代わりに受け取るようになった回答の中に居続けるのか、そのどちらかを選ぶことになります。 ネット上の助言の多くは、まず立場を決めてから、その立場だけを弁護します。誠実な言い方をすれば、正解...
Cloudflare Queues は、サーバーレスアプリケーションが遅かれ早かれ必ず突き当たる問題を解決します。すなわち、ユーザーを待たせるべきではない処理を引き起こすリクエストが届く、という問題です。確認メールの送信、アップロードされた画像のリサイズ、レコードを外部サービスへ同期する処理。従来型のサーバーであれば、そうした仕事はバックグラウンドのワーカープロセスに渡せば済みます。ところが Workers には、渡す相手となるプロセスそのものが存在しません。 よく使われる回避策は、見た目よりもたちが悪いものばかりです。処理をリクエストの中でそのまま実行すれば、ユーザーはメール配信事業者の応答を待たされることになります。...
Cloudflare Hyperdriveは、きわめて具体的で、まったく華やかさのない問題のために存在しています。200の都市で走っているWorkerが、たった一つの都市に置かれた一つのPostgresデータベースと会話すると、そのデータベースのすぐ隣に座っているサーバーから同じクエリを投げた場合よりも遅くなります。少し遅い、という話ではありません。多くの場合は数倍遅く、しかもその理由は、クエリがどう書かれているかとはまったく関係がありません。 サーバーレスのアプリケーションが重たく感じられたとき、最初に働く直感は、クエリプランナーのせいにするか、インデックスをもう一本足すかのどちらかです。しかしリージョンに置かれたデータベースと会...
ECサイトのGEOは、記事コンテンツのGEOよりも範囲の狭い問題であり、ある一点においてはむしろ簡単です。商品についての質問に答えようとするアシスタントが欲しがるのは、言い切っても差し支えのない事実だからです。価格、在庫の有無、寸法、対応機種、返品を受け付ける期間。これらは機械が読み取れる形であなたのサイトに存在しているか、存在していないかのどちらかであり、存在していないものは引用のしようがありません。 つまりこれは文章の問題というより、データの問題です。作業の大半は商品フィードとマークアップの側にあり、販売用の文章の側にはありません。この分野の他のあらゆるテーマとは、ちょうど逆の構図になっています。 採用を決めるのは網羅性よりも正...
かつて検索エンジン最適化を測っていたやり方で、GEOを測れる人はいません。理由はツールが足りないことではなく、構造そのものが変わったことにあります。古い指標はどれもクリックが起きることを前提にしていました。順位を知る価値があったのは、順位が流入を予測し、流入が売上を予測したからです。ところが訪問を伴わずに答えが手渡されると、この連鎖は最初の環で切れてしまい、その下流にあるすべての数値は何も変わっていないかのように同じ顔で報告を続けます。 危ういのはまさにそこです。順位は正常に見えます。セッション数もまだ耐えられる範囲に見えます。ダッシュボードは緑のままなのに、あなたが本当に気にしている中身はゼロへ向かっており、標準的なレポートにはそ...
複数拠点のSEOは、試みるほぼすべての事業者で同じように失敗します。誰かが良いサービスページを一枚書き、支店ごとに複製し、地名を差し替え、九十五パーセントが同一の十二枚を公開します。規模を広げた気分になります。しかし振る舞いは重複であり、どこかを助けるどころか、すべての拠点を沈める方向に働きます。 その衝動は理解できます。同じサービスについて本当に異なる十二枚を書くのは、難しく費用もかかるからです。ただし近道が生むのは、検索エンジンが互いに優先する理由を持たないページ群です。だから一枚を選び、その順位も安定せず、残りは無視されます。 大半を解くひとつの原則: 拠点ページには、その拠点にだけ当てはまることが載っていなければなりません。...