6つ作った。アクセスは、ほとんどない
UTILIZABLEでは、データ作業に使う6つのツールを公開している。SQLを整形する。値の一覧をIN句にする。CSVの構造を見る。2つのCSVを比較する。DDLを読む。SELECT文からカラムやテーブルを拾う。
機能追加を続けることもできた。でも、今あるページがGoogleからどう見えているか分からないまま07、08、09と増やしても、アクセスが少ない理由は分からない。
そこで一度、新しいツールを作る手を止めた。今回は「SEOで成功した」という記事ではない。既存6ページの意味を伝わる形に整え、これから測れる状態を作る実験だ。
まず観測できる状態を作る。
動くページと、伝わるページは違う
ツールが正しく動いていても、HTMLを読んだだけで「何をするページか」「何を入力し、何が出るか」「どこまで対応するか」が分からなければ、検索エンジンにも利用者にも意味が伝わりにくい。
UTILIZABLEは操作UIを短く保つことを優先していた。その方針は変えない。H1、短い説明、ツール操作、その後に詳しい説明を置く。UIは上、説明は下。検索から来た人がツールを使うまでの距離は伸ばさない。
6ページを、同じ文章にしない
各ツールに固有の検索意図を設定した。キーワードを大量に並べるためではなく、ページごとの入力、処理、結果を普通の文章で説明するためだ。
- SQL FORMATTERSQL整形、インデント、Oracle / PostgreSQL
- SQL IN GENERATORリストやExcelの値をSQL IN句へ変換
- CSV INSPECTORCSV構造、列、欠損、最大長、推定型
- CSV DIFFキーによるCSV比較、追加・削除・変更行
- DDL ANALYZERCREATE TABLEからカラム、型、制約を抽出
- SQL COLUMN EXTRACTORSELECT、JOIN、CTE、基本的なcolumn lineage
実際のtitleとdescriptionは推測で作らず、各ページのHTMLと機能制限を確認した。6ページを同じdescriptionにせず、対応していない機能も書いていない。
説明を増やしても、ツールを遠ざけない
各ページにHow to use、What it does、Use cases、Supported features、Limitations、Privacy、Related toolsを追加した。検索エンジン専用の隠しテキストではなく、利用者にも意味がある可視コンテンツだ。
説明は操作領域の後へ置いた。1440pxでは説明パネルを2列、390pxと320pxでは1列にする。既存のブレークポイントを使い、モバイルで使いづらくならず、横スクロールが出ないことを確認した。
titleとdescriptionを、ページ固有にする
6ページのtitle、meta description、OGP、Twitter Cardを、実際の検索意図に合わせて調整した。canonicalとURLは変更していない。
SQL FormatterならOracle / PostgreSQLのSQL整形、CSV Diffなら一意キーによる2ファイル比較、DDL AnalyzerならCREATE TABLEの解析が主題になる。ページ名だけを差し替えた文章ではなく、何ができるか分かる内容にした。
これは順位を上げる魔法ではない。検索結果に現れたとき、Googleと利用者が6ページの違いを判断できる最低限の土台だ。
全部を並べず、近い道具をつなぐ
各ツールの末尾にRelated toolsを置き、用途の近い2ページへ通常のHTMLリンクを追加した。SQL FormatterからSQL Column Extractor、CSV InspectorからCSV Diff、SQL Column ExtractorからDDL Analyzerというように、作業の流れが自然につながるものを選んだ。
トップページの6ツールカードも通常リンクのまま維持した。各ページからPrivacy Policyへも導線を追加した。
WebApplicationとして、書いてあることを機械にも渡す
6ツールすべてにWebApplicationのJSON-LDを追加した。name、url、description、applicationCategory、operatingSystemには、実装済みHTMLにある正確な値を使った。
{
"@context": "https://schema.org",
"@type": "WebApplication",
"name": "SQL Formatter",
"url": "https://data.midnightbench.com/tools/sql-formatter/",
"description": "...",
"applicationCategory": "DeveloperApplication",
"operatingSystem": "Any"
}存在しないrating、review、price、user countは書かない。FAQ Schemaも使っていない。構造化データは、ページに実在する内容を別形式で伝えるものとして扱った。
SEOのために、入力データの扱いは変えない
SQL、CSV、DDL、解析結果などのツール入力はアプリケーションサーバへ送らず、ブラウザ内で処理する。今回もこの設計は変えていない。
Cloudflare Web Analyticsはページアクセス用として各HTMLで1回だけ読み込む。ツール入力をAnalyticsへ送るものではない。新しいtracking libraryや外部SEOライブラリも追加していない。
変更対象はmetadata、可視説明、内部リンク、JSON-LD、最小限のCSS。6ツールの解析ロジックと操作ロジックのJavaScriptには触れなかった。
HTML中心の変更でも、機能が壊れていないことを見る
変更後に既存テストを実行した。結果は73 / 73 successful、失敗0。6ツールの代表操作もブラウザで実行し、JavaScript runtime exceptionがないことを確認した。
titleとdescriptionの一意性、H1が1つであること、self canonical、OGP、Twitter Card、WebApplication JSON-LD、内部リンク、Analyticsが1回だけであることも検証した。robots.txtとsitemap.xmlは元から正常だったため、無意味に変更していない。
ローカルでは127.0.0.1からCloudflare RUMへ送信するとCORSエラーになる。これはAnalytics側のローカルorigin制約で、UTILIZABLE本体のJavaScriptエラーではない。本番設定は変更していない。
変更しただけでは、観測は始まらない
SEO Phase 1を公開した後、Google Search Consoleから主要ツールページのインデックス登録、再クロールを依頼した。サイトマップはすでに登録済みなので、正常な設定を変更することはしなかった。
- アクセスが少ない状態を確認する
- 原因の仮説を立てる
- 既存6ページのSEO Phase 1を実装する
- Search Consoleから再クロールを依頼する
- 一定期間、実データを観測する
結果は、まだ分からない
現時点で「アクセスが増えた」「順位が上がった」「SEOに成功した」とは言えない。変更と再クロール依頼を行ったばかりで、判断できるデータがない。
最初に見るのはPVだけではない。Search ConsoleのImpressions、Queries、Average position、Clicksを見る。Clicksがなくても、まず検索結果に表示され始めたかをImpressionsで確かめる。
最初の観測期間は約1週間。ただしGoogleのクロール、インデックス、検索表示には時間がかかる。1週間で結論を急がず、データが少なければ期間を延ばす。
SEOの結果は、まだ始まっていない。
次に変えるのは、データを見てから
今の段階で説明をさらに増やしたり、titleを毎日変えたりはしない。Search Consoleに実際のQueryが出てから、Googleがどんな検索語でページを表示しているかを見る。
想定した検索意図と実際のQueryが違うかもしれない。表示されてもクリックされないかもしれない。Phase 2は推測ではなく、そのデータを材料にする。
成功しても失敗しても、次の判断材料になる。次は「SEO Phase 1から一週間。Search Consoleでは何が起きたか」を書ける状態になった。
ここからは、待って測る。