自動生成のURLはシンプルなURL構造ではなかった！

はじめに
- なぜカスタムURLにすべきなのか
- 記事URL変更のリスク
  - 旧記事URL→新記事URLの自動転送はできる？
自動転送と404 Not Foundの対応方法

はじめに

はてなブログを始めて約26カ月（2年弱）が経過しましたが、ブログ運営で今一番気になっていることがあります。

それは何か分かりますか。

記事が少ない　・・・まったく思ってません
はてブが少ない　・・・少し思ってます
アドセンス収益が少ない　・・・今はしかたないと思ってます
読者数が少ない　・・・あまり思ってません
アクセスが少ない　・・・多少気にしてます
独自ドメインが弱い　・・・ともて気にしてます

正解は記事のページURLが自動生成だったことです。

なぜなら、既出記事のURLを変えると面倒くさいことが待っているからです。

これからブログを始めようと思っている方、始めたばかりの方は、カスタムURLを使用することを強くおススメします。

あとでやろうと思ったらダメです。被害を最小限にしたいなら今すぐ自動生成URLでのブログ公開は止めるべきです。

ついでにもう一つ加えると独自ドメインへの移行は早いにこしたことはないです。

独自ドメインに変えるのは、いつでも良いと思っていましたが、必ずしも正しい選択ではなかったことに最近気づきました。

当サイトの場合、旧ドメインに強いコンテンツが多いため、独自ドメイン（新ドメイン）に移行しても、独自ドメインのアクセスはなかなか増えないのです。

独自ドメインの過去3ヵ月のクリック数を調べたらは1日平均5程度しかなく、メチャ凹みました。

話を元に戻します。

なぜカスタムURLにすべきなのか

SEOを考慮するならURLは自動生成ではなくカスタムURLにすべきです。

理由は3つあります。

Googleにインデックスされないリスクがある

前回の記事で「公開した記事の33％がGoogleにインデックスされてなかった。」ということを報告しました。

ブログのアクセスが少ないのはGoogleにインデックスされてないからかも！ - after work Labo

はじめにインデックとはインデックスを登録する方法 Search Consoleの導入方法サイトマップとはサイトマップの登録カスタムURLの設定方法カスタムURL名の注意点カスタムURLの設定手順インデックス登録の方法 URLの検査まとめはじめに皆さんはご自分のブログのPV（Page View：ページビュー）を気にする方ですか、気にしない方ですか。私は多少気にしてる方です。多少と言っている理由はアドセンスを少...ているからです。しかしPVは多くないので収益はさっぱりです。私と違いアドセンスやアフィリエイトでそれなりの収益を得ている方は、PVを非常に気にされている…

本当にこのようなことが発生するのか気になるところですが、Googleはサチコ（Search Console）のガイドライン”シンプルなURL構造を維持する”で以下のように警告してます。

サイトの URL 構造はできる限りシンプルにします。

論理的かつ人間が理解できる方法で（可能な場合は ID ではなく意味のある単語を使用して）URL を構成できるよう、コンテンツを分類します。

たとえば、航空機（aviation）に関する情報を探している場合、http://en.wikipedia.org/wiki/Aviation のような URL であれば、見ただけで必要な情報であるかどうかを判断できます。http://www.example.com/index.php?id_sezione=360&sid=3a5ebc944f41daa6f849f730f1 のような URL 自体は、ユーザーの関心を引くことはほとんどありません。

URL では区切り記号を使うと効果的です。

http://www.example.com/green-dress.html という URL の方が、http://www.example.com/greendress.html という URL よりずっとわかりやすくなります。

URL にはアンダースコア（_）ではなくハイフン（-）を使用することをおすすめします。

特に複数のパラメータを含む URL など、過度に複雑な URL は、サイト上の同じまたは同様のコンテンツを表す多数の URL を不必要に作成し、クロールの際に問題が生じることがあります。

その結果、Googlebot で必要以上に帯域幅を消費したり、サイトのすべてのコンテンツをインデックスに登録できないことがあります。

内容が素晴らしく完璧なキーワードのタイトルの記事でも、GoogleBot（クローラー）がインデックスしなかったら検索では探し出せません。

バズらない限り誰も読んでくれないでしょう。当然収益にはつながりません。

記事のリライトが楽

通常記事を公開したらカスタムURLには自動生成したファイル名が入ります

記事をリライトするために下書きに戻すと、カスタムURLは空欄に戻りファイル名が消えてしまいます。

この状態で投稿日時を更新し再公開すると、はてなスターとはてなブックマークが0にリセットされてしまうので、カスタムURLに自動生成のファイル名を再入力し公開する必要があります。

この手順で自動生成のファイル名を失念してたり間違えたらOUTですね。

最初からカスタムURLで記事を公開していれば、下書きに戻してもカスタムURLの文字は消えずに残ったままなので、手間がかからず、つまらないミスを回避できます。

ブログ分析で困まる

これは当ブログの過去3ヵ月のクリック数ベスト10のページURLです。

クリック数が少なすぎるのは置いといて、自動生成のURLは年月日時分秒で構成された記号なので、記事を書いた本人にも、URL名からはどんなジャンルの記事かわかりません。

PCでドキュメントを作成し保存する際、保存フォルダを年月日にする場合はありますが、ファイル名を年月日にする人はいないと思います。

従って、どんな記事かわからないファイル名だと分析に時間がかかり、対策を考える時に面倒ですね。

一方カスタムURLで記事のタイトルと相関を持った意味がある単語で構成されたファイル名であれば、何の記事か容易に想像することができます。

記事URL変更のリスク

カスタムURLに変えるまでの期間、どんな弱小ブログも多かれ少なかれ自分のページにリンクが貼られていると思います。

自分の記事に興味を持ったユーザが外部リンクから訪問した時、カスタムURLに変わっていたら「Not Found：お探しの記事は見つかりませんでした。」となってしまいます。

検索からの訪問も同じで、肝心の記事が存在しなくガッカリすることになります。

ひょっとしたらブログを廃止していると勘違いされ、二度と訪問されないかも知れません。

またブックマークしたユーザは、後で読もうとリンクを開いて存在しなかったら、この記事は炎上したので削除したのかな、と勘違いするかも知れません。

更に、はてなでは記事のURLが変わると「はてなスター」と「はてなブックマーク」が0にリセットされます。

これまで時間をかけて積み上げてきたものが一瞬で無くなり、見かけ上誰からも記事を読まれてないような状態になります。

互助会ユーザだったら、失望・落胆してしまい、ブログ継続のモチベーションがガックと下がってしまうかも知れません。

記事URLを変えるのはデメリットが大きいのです。

リテラシー（literacy）がある人は最初からカスタムURLを使うと思いますので、以上のことで悩む必要はありません。

リテラシーとは何かも知らないリテラシーが無い人はどうすれば良いのでしょうか。

旧URLを新URLに自動転送すればよいのですが、リテラシーが無い人は変更前の旧URLを記録してない恐れがあります。

自動転送しようと思っても、そもそも旧URLのアドレスが分からなかったら、新URLのアドレスには転送できません。

何も考えずにURLを変えると地獄を見ると言ったのは、旧URLのアドレスを探し特定する作業が大変なのです。

旧記事URL→新記事URLの自動転送はできる？

仮に旧URLが分かっている場合、次のハードルが待ち構えてます。

http→https移行の変更はGoogleが自動転送してくれます。ドメイン名変更については、はてなブログが自動転送してくれます。

しかし、個々の記事ページを転送するサービスはどこからも提供されてないのです。

個々の記事ページの自動転送は、自分でJavaScriptでプログラムを作り、Webサイトに実装する必要があります。

これは初心者にはハードルが高く面倒くさいですね。

JavaScriptは昔やってみようと思い参考書を衝動買いしましたが、目次に目を通しただけで、興味がある命令を数えるほどしか勉強しませんでした。

ブログのヒーローヘッダーにきれいなお姉さんを表示するJavaScriptは、スケベな気持ちに支えられ、何とか頑張ってつくりましたが、スケベとは関係ないものはやる気が起きません。

グダグダ言い訳を書きましたが、先人がつくったプログラムを少し修正すれば、サイトに実装できることが分かったので、少しやる気が芽生えました。

幸い“あトん”は怠け者なので記事は50弱しか存在しません。

ブログのページのほとんどをカスタムURLに変えたら、一体どんな結末になるのか興味もあったので、ここは人柱になってみようと思いました。（偉い！無謀？）

自動転送と404 Not Foundの対応方法

自動生成URLをカスタムURLに変更すると、外部リンク、内部リンクから旧URLにアクセスした際、404 Not Foundになってしまいます。

内部リンクは頑張れば力づくでの修正は可能ですが、外部リンクの修正不可能です。

例えば、はてなブックマークはエントリータイトルの修正は出来ますが、元記事のURLの修正はできません。

対応策として、旧URLへのアクセスがあったら新URLに自動転送するJavaScriptを組み込みます。

今回作成したJavaScriptは二部構成となってます。

第一部は設定したアドレスへの自動転送で、第二部は存在しないページ（未登録アドレス）に対するお詫びと別記事への誘導です。

第一部の作成は「blogcustomize」様のプログラムを参考にさせて頂きました。

【はてなブログ】新記事URLにリダイレクトする方法

私もカスタムURLで変更する前に記事を公開してしまったということが頻繁にあるのですが、この場合に元のURLで更新情報を知らせる機能のRSSが飛んでしまい読者が記事に辿りつけないという自体に

第二部の作成は「lightgauge」様のプログラムをまるまる参考にさせて頂きました。

はてなブログの404 NOT FOUNDページをカスタマイズする方法 - 攻めは飛車角銀桂守りは金銀三枚

404 NOT FOUNDページ。サイトに存在しないURLを指定された時にでるページです。はてなブログの「404 NOT FOUNDページ」を簡単にカスタマイズする方法です。

「blogcustomize」様「lightgauge」様のお二人には深く感謝いたします。

事前準備

自動転送用の変更前・変更後のURL対応表を忘れずに作っておいてください。

また、404 Not Foundに対しては、お詫びの画像を用意しておくと良いでしょう。

なお、URLを変更するページが非常に多いは、無理に全部変更する必要はないと思います。

リクスが少ない記事、今後アクセス増が見込める記事等に限定し、最初はしばらく様子を見て下さい。

自動転送のコード

JavaScriptのコードはCodePenに保存しました。

See the Pen はてな用404 by aTn (@git-atn) on CodePen.

どのようになっているか、少し解説します。

第一部（自動転送）の構成

はてなブログの記事URLは下のような構造になってます。

https://ドメイン名/entry/年/月/日/時分秒

「entry」というディレクトリの下に記事のページが格納されてます。

つまり、すべての記事に共通なURL部は「https://ドメイン名/entry/」で、ページ毎にユニークなファイル名が「年/月/日/時分秒」です。

記事URLの構造が分かったので、メモリとJavaScriptのコードを最小にするため「年/月/日/時分秒」のみをカスタムURLに置換し、自動転送するようにしました。

ファイル名はコロンで囲い、左側が変更前、右側が変更後のファイル名です。

記述例：['2018/12/10/001825', 'windows10-memory-expansion']

なお、自動転送の待ち時間は0となってます。

「本記事へのアクセスありがとうございます。記事のURLが新しく変わったので、3秒後に自動転送します。」等の表示は割愛しました。必要に応じてご自分で追加下さい。

第二部（お詫びと別記事表示）の構成

Adsenceに合格するためにポリシー違反のページや価値の低い記事を下書きに戻し非公開にする場合があります。

また、サイトの価値を下げるどうでも良い記事を整理して削除することもあります。

これらの記事にアクセスが発生した際、「Not Found：お探しの記事は見つかりませんでした。」の表示だけだと素っ気ないですよね。

サイト自体が存在しないと勘違いされる恐れもあります。

記事が見れない理由を説明し、他の記事を紹介できると「親切なサイトだなー」と興味をもってもらえるかも知れません。

使用方法

管理画面の「デザイン」→「⚙（カスタマイズ」→「フッタ」に①②をペーストして下さい。

①jqueryのペースト

既に登録済であれば不要です。

<script type="text/javascript" src="https://cdn.blog.st-hatena.com/js/external/jquery.min.js?version=1.12.3">
</script>

②本体のペースト

旧URL名、新URL名、ドメイン名、お詫びの画像アドレスは、自サイトに合わせて修正し、ペーストして下さい。

<script>
// 複数の旧URLを新URLのアドレスに転送
var urlDir = [
    ['oldURL1', 'newURL1'], // oldURL:旧URL　newURL：新URL　を指定
    ['oldURL2', 'newURL2'],
    ['oldURL3', 'newURL3'],
    ['oldURL4', 'newURL4'],
    ['oldURL5', 'newURL5']
];
var comURL = 'https://ドメイン名/entry/' // 共通URL部　ドメイン名を指定
var wordCOUNT = comURL.length; // 共通URL文字数をカウント
var str = location.href;
for (var i = 0; i < urlDir.length; ++i) {
    var oldDir = comURL + urlDir[i][0];
    var newDir = comURL + urlDir[i][1];
    if (str.substr(0, wordCOUNT + 17) == oldDir) {
        setTimeout(function() {
            location.href = newDir;
        }, 0); // 0秒で転送
        break;
    }
}

// 404エラー対応
$(document).ready(function() {
    if ($('#main-inner').children().hasClass("no-entry")) {
        var content = "<br/><center>『after Work Labo』へご訪問いただきまして誠にありがとうございます。</center>";
        content += "<center>お探しのページはリテラシーがない管理人が手違いで削除したものです。</center><br/>";
        content += "<center><img src='お詫びの画像アドレス' width='60%'></center>";
        content += "<br/><center>今のところ記事の再公開・リライトは未定です。</center><br/><center>お探しの記事の代わりになるかわかりませんが、</center>";
        content += "<center>当ブログで多く読まれている人気記事を宜しければご笑覧ください。</center><br/><br/>";
        content += "<div class='hatena-module hatena-module-entries-access-ranking'";
        content += "data-count='5'"; // 表示件数
        content += "data-source='access'"; // access:人気順  total_bookmark:ブックマーク数順 recent_bookmark:新着順
        content += "data-enable_customize_format='0'";
        content += "data-display_entry_category='0'";
        content += "data-display_entry_image='1'";
        content += "data-display_entry_image_size_width='105'";
        content += "data-display_entry_image_size_height='90'";
        content += "data-display_entry_body_length='0'";
        content += "data-display_entry_date='1'";
        content += "data-display_entry_title_length='20'";
        content += "data-restrict_entry_title_length='0'";
        content += "data-display_bookmark_count='1'";
        content += ">";
        content += "<div class='hatena-module-body'>";
        content += "</div>"
        content += "</div>";
        $('.entry-footer').html(content);
    }
});
</script>

なお、紹介記事の表示はサイドバーのモジュール編集の設定と同じにしました。