タグ: SEO

用語集の分類ページを調べていて、妙な指定に気づきました。このページは「記事」だと名乗っていました。

中身は用語が並んだ一覧です。公開日もなければ、書いた人もいません。それでも、SNSや検索エンジンに向けては「これは1本の読み物です」と伝えていました。

既定値をそのまま連れてきていた

SNSで共有されたときの見え方を決める指定に、type という項目があります。1本の記事なら article、そうでないページは website です。

用語集の分類ページには、こう書いてありました。

openGraph: {
  type: "article",
  title,
  description: cat.description,
}

記事ページの書き方をそのまま持ってきた形跡です。動かして確かめる対象ではないので、間違っていても画面には何も出ません。

同じ書き方がプライバシーポリシーにもありました。こちらも読み物ではありません。2ページとも website に直しました。

何も名乗っていないページが4つあった

ついでに構造化データを数えました。検索エンジンに「このページは何か」を直接伝える仕組みで、画面には出ません。

記事ページだけ揃っていて、それ以外は空でした。記事を書くときに考えたことが、そのとき触っていたファイルの中で完結していたわけです。

記事用の部品を広げるか、別に作るか

足すにあたって、記事用の部品を使い回すか迷いました。

使い回そうとすると、日付の扱いで詰まります。記事には公開日があり、一覧にはありません。「日付が無いときは書かない」という枝を足すことになります。そのうち書き手についても同じ枝が必要になり、部品の中身が条件分岐で埋まっていきます。

パンくずは全ページに付けました。検索結果に出る階層表示に使われるもので、画面上の階層と一致していないと逆効果になります。実際のURLの形をそのまま写しただけです。

ドメイン名が4か所に書いてあった

作業中に、別の問題が見えました。サイトの絶対URL https://www.kisaku.site が、4つのファイルにそれぞれ書いてありました。

robots.txt を作るところ、サイトマップを作るところ、RSSを作るところ、構造化データを作るところです。共通しているのは、どれも画面に出ない場所だということでした。

ページの head に入れる相対パスは、設定してある基準URLが絶対URLへ直してくれます。直してくれないのは、この4か所のように文字列を自分で組み立てている場所だけです。

1か所にまとめて、そこから読む形にしました。ドメインを変える日に1つ書き換え忘れても、画面を見ているかぎり気づけない種類の値だからです。

今回の学び

まず、ページは自分が何であるかを名乗っているということ。画面に出ない場所で、公開日や書き手を持つ読み物だと宣言していました。表示は正しく、指定だけが実態とずれていました。動かして確かめる対象ではないので、読みに行かないかぎり分かりません。

次に、書き方をコピーすると、意味もコピーされること。記事ページの指定を持ってきたのは自然な流れですが、その中には「これは記事です」という宣言も含まれていました。形だけ借りたつもりで、中身まで一緒に来ていたわけです。

そして、条件分岐が増えそうなときは、分ける合図だと考えること。1つの部品で両方をまかなおうとすると「日付が無いとき」「書き手が無いとき」の枝が並びます。それは、そもそも別のことを言おうとしている合図でした。

1行足したつもりでした。実際には、そのページの共有画像が消えていました。

しかも消えたのは、その日に触ったページだけではありません。調べたら、以前から9ページで同じことが起きていました。画面には出ず、動作も壊れず、誰も気づいていませんでした。

正規URLを足しに行っただけだった

きっかけは検索エンジン側の指摘でした。ブログ一覧に絞り込みが付いているため、同じ中身が複数のURLで見える状態になっていて、56件が「重複しています」と報告されていました。

対処として、各ページに「このページの代表URLはこれです」という指定を足しました。Next.js では alternates というかたまりの中に書きます。

// 記事一覧ページ
export const metadata = {
  alternates: {
    canonical: "/blog",
  },
};

足したのは1項目です。ところが公開後に確認すると、そのページからRSSフィードの場所が消えていました。

親に書いてあったものが、丸ごと消えた

フィードの場所は、全ページ共通の設定として親の側に書いてありました。

// 全ページ共通の側
alternates: {
  types: {
    "application/rss+xml": [{ url: "/feed.xml", title: "..." }],
  },
},

期待していたのは、親の types はそのまま残り、子で足した canonical が加わることです。実際は違いました。

購読アプリはブログ一覧を最初に見に来ます。そこから場所が消えるのは困ります。

同じ形が、すでに別の場所で起きていた

この仕組みが分かった時点で、嫌な予感がしました。同じ書き方をしているかたまりが、もう1つあるからです。SNSで共有されたときの見え方を決める openGraph です。

共有画像は親の側に1枚だけ置いてあり、各ページはそこに乗るはずでした。ところが個別のページには、こう書いてありました。

export const metadata = {
  openGraph: {
    title: "...",
    description: "...",
  },
};

画像の指定はありません。画像を消すつもりも、当然ありません。それでも alternates と同じ理屈で、親の openGraph はまるごと捨てられます。画像だけが残るということは起こりません。

公開中のページを1つずつ取り寄せて、実際のHTMLを見ました。

合計9ページで画像が出ていませんでした。og:title は書いてあるので、確認する側から見ると「設定してある」ように見えます。抜けているのは、書いていない項目のほうでした。

なぜ長いあいだ気づかなかったのか

この不具合には、気づくきっかけがほとんどありません。

画面には何も出ません。ページは普通に表示され、リンクも動きます。ビルドも通ります。書き間違いではないので、警告も出ません。「書いていないものが消える」ので、書いたものを見ているかぎり異常が見えません。

書き写すのではなく、1か所から読む

直し方は単純で、上書きするページでは、消えるものを毎回書き添えます。

ただし各ページに同じ内容を書き写すと、いずれ書き忘れます。今回消えていた9ページは、まさに書き忘れの集まりでした。同じ直し方をすれば、同じことが起こります。

そこで、共通の値を1か所に置いて、そこから読む形にしました。

export const FEED_ALTERNATE_TYPES = { /* ... */ };

export function alternatesFor(canonicalPath) {
  return {
    canonical: canonicalPath,
    types: FEED_ALTERNATE_TYPES,
  };
}

各ページは alternatesFor("/blog") と書きます。「canonical を足す」と書けば、消えるはずのものが自動で付いてきます。共有画像のほうも同じ形にして、既定の画像を1か所に置き、上書きするページはそれを混ぜて返すようにしました。

今回の学び

まず、設定を足すときは「入れ替わる単位」を先に確かめるということ。項目ごとに混ざると思い込んでいたので、1項目を足す作業のつもりでいました。実際にはかたまりの差し替えでした。足し算だと思っていた操作が、代入だったわけです。

次に、1件見つけたら、同じ形を探しに行くこと。今回いちばん役に立ったのは、直したことではなく「同じ書き方をしている場所は他にないか」と考えたことでした。目に見える不具合は1つでしたが、同じ形をした見えない不具合が9つありました。

そして、自分の画面に出ない設定は、外から取り寄せて確かめること。共有時の見え方も、検索エンジン向けの指定も、開発中の画面には出てきません。公開中のHTMLを1ページずつ取り寄せて初めて、書いてあるつもりのものが無いと分かりました。書いたコードではなく、出ている結果を見る必要がありました。