2025年10月14日　そこにあるのに見えないサイト

Kitakami Yuma Project.のyumaです。

今回はちょっと個人的に気になったことを調査しました。
多くの方には無関係かもしれませんが、誰かの助けになるかもしれないので記録します。

今回もまた蛇足が多いですがご愛敬。
大体九割以上が蛇足です。
結論だけ早く見たい方はこちらから飛ばしてください。

まず何があったのかご説明します。
簡潔に言うと以前まで検索に出ていたサイトが出てこなくなりました。

先日「中村のマインクラフト造船」というサイトへアクセスしようとGoogleで検索しました。
そしたら以前は検索に出てきたにもかかわらず、今回はトップページ以外のページも含む全てのページが表示されませんでした。

まさかサイトが閉鎖してしまったのか！？
最悪の事態を想像しながらサイトを運営している中丸・中村造船さんのYouTubeチャンネルにあるリンクから飛んでみたところ、幸いサイト自体は残っていました。

最悪の事態は免れましたが、一つの疑問が生じました。
何故Googleの検索に引っかからないのかと。

自分のサイトじゃないんだし無関係なんだからどうでもいいじゃないか。
そう思われる方もいるかもしれません。

ですが中村のマインクラフト造船と僕の北上ゆま 公式HPには共通点が存在します。
それはどちらも個人で作った規模の小さいサイトであること。

もしこの現象の原因は規模の小ささであった場合、僕のサイトにも同じことが起こる可能性があるということです。
これは調査を行うしかないでしょう。

まず軽くGoogleで「nnz-design.com」と検索してみました。
こうすれば本当に全部消えているか確認できますし、「nnz-design.com」と書いてあるサイトを見つけることができます。

結果は残念ながら中村のマインクラフト造船のページは1つも出てきませんでした。
しかしとある見たことのないページが検索に引っかかりました。

NNZ Third blog – Just another WordPress site

NNZは中丸・中村造船の略と思われるもので、中丸・中村造船さんの動画やサイトにもよく登場します。
しかしこのサイトはnnzdesign.shopとなっており、FaviconもWordPressのデフォルトです。

正直中丸・中村造船さんのサイトには思えません。
僕は怪しみながらそのサイトを開きました。
.shopとか如何にも怪しいですし。

すると中丸・中村造船さんのサイトなのが分かり、また今回の件も書いてありました。
サイトの情報を軽く要約します。

Googleのインデックスが何故か解除される事件が発生。
対策を行ったものの効果なし。
現在も原因不明。

ここからわかることは今回の件が意図したものではないこと。
不明なもの以上に恐ろしいものはありません。

それから本腰を入れて調べることにしました。
まずは問題が起きている中村のマインクラフト造船と、僕の北上ゆま 公式HPを比較してみることにしました。

何故比較しようと思ったかは比較して異なる点が原因の可能性が高いと思ったからです。
すると結構意外な情報が手に入りました。

上のテーブルはそれぞれのサイトを比較したものです。
まず一番驚いたのはドメインを管理している会社が同じであること。

個人のサイトだとネームサーバーを見れば大体どのレンタルサーバーか分かることが多いのでWHOISを見てみたんですよね。
まあ今回はWHOISを見てもわかりませんでしたが。
そしたら見覚えのある名前が出てきて驚きました。

流石にWHOISの内容をコピーするのは問題がありそうなのでやりませんが、WHOIS検索という便利なサイトで2つのサイトのWHOISを見てください。
作成日や更新日、有効期限、ネームサーバーこそ多少の違いはありますが、それ以外は完全に一致しています。

ドメインを管理している会社が数多も存在する中、まさかの全く同じところで驚きました。
まさかこんなことが起きるなんて。

ちなみにドメインの登録者が記録されているWHOISに僕や中丸・中村造船さんの個人情報が載っていないのは、どちらもWhois情報の代理公開を行っているからでしょう。
最近は個人情報の問題から、ドメインを管理している会社の情報を代理で公開することも多いんですよね。

とまあ少々驚きましたがここからわかることはドメイン管理会社のトラブルではない可能性が高いということでしょう。
同じサービスを使ってるので分かりますが、XServerドメインで障害が起きているという情報は届いてません。

Whoisの情報が不正確だとトラブルが起きるというのを聞いたことありますが、2つのサイトのWhoisがほぼ同じである以上これが原因となっている可能性は限りなく低いでしょう。
そもそもURLを直接入れればアクセスできますし、ドメインが原因は最初からそこまで考えてませんでしたけどね。

またトップレベルドメイン(.com)側に問題が発生している可能性も限りなく低いでしょう。
なにせどちらも同じ.comですからね。

ドメインの問題は無いと判断したため次はサイトのソースコードに目を付けました。
ちなみにこの時はサーバーがXServerだと勘違いしていました。

ソースを見たのは<meta name="ROBOTS" content="NOINDEX,NOFOLLOW">を誤って書いていたり膨大なエラーで変なことになっていないか確認したかったからです。
過去にAmazonのエラーでChromeがブロックしたなんて話もありますし、同じGoogleなのでソースコードのエラーで弾いても不思議ではないと感じたからです。

AmazonのWebサイトで、商品のサムネをクリックしても画像が切り替わらない問題
どうやらAmazon側の問題らしく、HTMLのaria-hiddenの使い方が間違ってるのでブラウザがブロックしたらしい（アクセシビリティ的にNGらしい）。 pic.twitter.com/QiyiVq7nfF

— 🐧かめねこ🐧 (@kameneko1004) September 16, 2024

というわけで見てみたわけですが、多少のエラーはあるものの特にここまでの事態を引き起こすほどの問題は見つかりませんでした。
そもそも大抵のサイトは多少なりともエラーがあるので、もしエラーがあるので検索に出ませんなんて言ったらほとんどのサイトが引っかかるでしょう。

意外だったのはHTMLを直接書いている可能性が高いというところですね。
てっきりWordPressとか使っているものかと思いました。

最近はWordPressといったサイト作成ツールで作ることが多く、HTMLをフルスクラッチしたサイトはかなり少数派です。
僕のサイトはかつて使ってたXfreeの都合上、フルスクラッチで作るしかありませんでしたがまさか中丸・中村造船さんもフルスクラッチで作っているのは驚きでした。

ちなみにフルスクラッチだと判断したのは、WordPressとかにありがちな何を書いてるのか分かりにくい超長い謎コードじゃなかったからです。
なので確実にフルスクラッチであると断言するのは難しいです。

まあmetaのname="generator"が無いので十中八九フルスクラッチだと思われますが。
ちなみにWordPressもname="generator"があるので気になる方は見てみてください。

ちょっと脱線し過ぎましたね。
中村のマインクラフト造船にあったエラーは主に2種類で、imgの画像がねぇぞってエラーとscriptのJavaScriptがねぇぞってエラーです。
栗原ーーーーーッッッ！！！窓ねぇぞ！！！！！！！！！！！

トップページ以外に致命的なエラーがあるのかと思い調べましたが、結局はトップページにあるエラーと同じエラーがあるだけでした。
正直ありがちなエラーなのでこれだけで検索に出ないとは到底思えません。

なお今回見つかったエラーが発生するページはこちらです。
文字数が長くなるのでhttps://zosen.nnz-design.com/は省略しています。

勢い余って調べ過ぎましたね(笑)
他人が作ったもののエラーを探すなんて粗探しみたいで嫌ですが、今回はかなり重大な問題なため調べました。

こんなことやったら嫌われそうですね……。
まあ今回は何が原因かわからない以上、小さなトラブルも見逃すわけにはいかないので仕方ありませんが。

エラーではありませんが個人的に気になったことや、驚いたところがあったので書きたいと思います。
HTMLに関しては色々学んできたつもりですが、まだまだ知らないことも多いんですね。

トップページだけの特徴ですが、最初のhtmlタグにlang=ja dir="ltr"って属性が付いてるんですよね。
このdir="ltr"が知らなかったので驚きました。

どうやらテキストの進行方向を指定する属性で、dir="ltr"と指定すると左から右の文章であると設定できるそうです。
し、知らなかった……。

HTML dir グローバル属性 - HTML | MDN

詳細な説明は他のサイトに任せるとして、こんな属性があるんですね～。
全く知らない属性でしたが、調べてみたらX(旧Twitter)のhtmlタグにもありました。

あと調べてみて知ったのですが、属性って一定の条件に当てはまるなら"(ダブルクォーテーション)が無くても大丈夫なんですね。
lang=jaって行けたっけ？って思い調べてみたら普通にOKなんですね。

HTML 属性リファレンス - HTML | MDN

調べたところ一定の条件で書かれた属性なら省略して書いても良いそうです。
これも知らなかった……。

解説サイトを見たところ従来の"(ダブルクォーテーション)で囲むスタイルが冗長と書かれていてかなり驚きました。
とはいえあまり"(ダブルクォーテーション)を省略して書くサイトは見かけませんし、これが無いとVS Codeの拡張機能がエラーを吐くのでこれからも書くでしょう。

とはいえ知らないで囲んでいるのと知っていて囲んでいるのとでは大違いですからね。
今回新たな収穫があって非常に良かったです。

個人的に意外と感じたんですが、OGPが無いんですよね。
広報に結構力を入れている方なので意外でした。

OGP(Open Graph Protocol)とは、Facebookが開発したSNS上でサイトが共有された時に、サイトのタイトルや概要、URL、画像を表示するための仕組みです。
X(旧Twitter)でYouTubeの動画のURLを書いたら勝手にサムネが表示されるアレです。

OGPはhead内にmetaを追加することで設定できます。
簡単に設定できて目に留まりやすくなるので個人的におすすめです。

せっかくなので軽くOGPの使い方を説明しましょうか。
こんなこと書く機会はありませんからね。
そもそもこのサイト自体自己満足の塊だし。

流石に長くなり過ぎたので解説を飛ばせるようにしました。
もし飛ばしたい方はこちらをクリックしてください。

以下のソースコードはOGPを使う最小限のコードです。
これらのコードをhead内に入れることで簡単に使うことができます。

<meta property="og:title" content="ページのタイトル">
<meta property="og:type" content="ページの種類">
<meta property="og:url" content="ページのURL">
<meta property="og:image" content="画像のURL">

本来であればhtmlタグにprefix="og: https://ogp.me/ns#"って入れないといけないみたいですが、なくても普通に使えます。
Facebookでは知りませんが少なくともX(旧Twitter)では普通に表示されました。

それぞれの細かいルールはこんな感じです。

また追加で情報を入れることも可能です。
こちらはその中でよく使われているものです。

<meta property="og:description" content="ページの軽い説明">
<meta property="og:site_name" content="ウェブサイトのタイトル">
<meta property="og:locale" content="ページの言語">

この中だとog:descriptionが最もよく使いますね。
表示のパターンにもよりますが、他2つは表示されませんがog:descriptionはX(旧Twitter)で表示されるので。

こちらもそれぞれの細かいルールを書きます。

もっと詳しく知りたいのであれば公式のリファレンスがあるのでそちらをご覧ください。
The Open Graph protocol

厳密にはOGPではありませんがX(旧Twitter)にも似た機能があり、Cardという機能があります。
Twitterカードと訳されることも多いですが公式的には「カード」だそうです。

カードを使用するために必須なコードは1つだけです。
それがこちら。

<meta name="twitter:card" content="カードのタイプ">

これの書き方はこんな感じ。

こちらも追加の情報を色々追加することができます。
なお一部はOGPで代用することも可能です。

<meta name="twitter:site" content="ページの@ユーザー名">
<meta name="twitter:creator" content="作成者の@ユーザー名">
<meta name="twitter:description" content="ページの軽い説明">
<meta name="twitter:title" content="ページのタイトル">
<meta name="twitter:image" content="画像のURL">

twitter:site、twitter:creatorと酷似したものにtwitter:site:id、twitter:creator:idがありますが、違いは正直わかりません。
:idと付くものはもしかしたら内部的な数字の羅列のIDを用いるのかもしれませんね。

ちなみに細かい仕様はこんな感じです。

こちらも詳しい仕様が公開されているのでもっと知りたい方はそちらをご覧ください。
ちなみに日本語版じゃない理由は詳しい情報が日本語版にはないからです。
Cards markup | Docs | Twitter Developer Platform

そんなOGPとカード(Twitter)ですが、カードは一部をOGPで補うことができるため混在して使われることが多いです。
僕も昔はカードだけ書いてましたが今はOGPと組み合わせて使用しています。

実例をお見せしましょう。
僕の北上ゆま 公式HPからソースコードを持ってきました。

<meta name="twitter:card" content="summary_large_image">
<meta name="twitter:site" content="@Kitakami_Yuma_">
<meta name="twitter:creator" content="@Kitakami_Yuma_">
<meta property="og:title" content="北上ゆま 公式HP">
<meta property="og:description" content="バーチャルYouTuber「北上ゆま」の公式ホームページ。ここには北上ゆまの素材や資料が置いてあるよ！気になった人はぜひYouTubeチャンネルも見てね。">
<meta property="og:type" content="website">
<meta property="og:url" content="https://kitakamiyuma.com/">
<meta property="og:image" content="https://kitakamiyuma.com/images/og_image.webp">

必要最低限のところにtwitter:siteとtwitter:creatorとog:descriptionを加えた感じですね。
元々TwitterカードがあったところにOGPを入れたのでTwitterカードが上にありますが、OGPがtwitter:cardの上にあっても問題ありません。

様々なサイトを確認したところYouTubeの再生ページはこちらと逆でした。
こういうのを観察するだけでも面白いですね。

ちなみにtwitter:siteとtwitter:creatorを設置したのは単なる趣味です。
実用性はありませんがせっかく付けれるのなら付けてみようと思った次第です。

なおこの隠しサイトには基本的にOGPは設定していません。
理由は隠しサイトなので極力容量削減したいのと、OGPなんて無い時代のサイトをモチーフに作ってるからです。

別にサブドメインだから出来ないとかではありません。
ただOGPで堂々と表示するよりURLしか表示されないほうが、この少し不気味な雰囲気に合ってるでしょう。

っとまた脱線し過ぎましたね。
話がそれてしまうのは悪い癖なので直したいですね。
今回は深夜テンションが暴走した結果だけど……。

次に目に付いたのはインデントがスペース2個なところです。
中村さんってスペース2個タイプなんだーって感じました。

インデントって結構派閥争いが大きく、きのこたけのこ戦争のようにタブとスペースで争いが起きていて、同じスペースでも2個か4個かでまた争いが起きています。
中にはスペース8個派やスペース3個派なんて派閥もあるそうです。

正直だからなんだって話ですが、堅実にタブを使ってそうな印象だったので意外でした。
まあ本当にだから何って話ですがね(笑)

ちなみに僕はルールが決まってない限り、基本的にタブで書いています。
理由は自分一人でしか作業しないのでスペースを使うことによる環境に左右されない恩恵が薄いからです。

あと単純にVS Codeの初期設定がTabキーでタブを使うようになっているからです。
正直こっちの方が大きいですね。
わざわざ設定を変えるのは面倒だもの。

ちなみにタブとスペースではスペース派の方が多く、その中でも中村さんと同じスペース2個派が最も多いそうです。
そういう意味ではこのサイトは少し古めかしいですね。
見た目が古臭いんだからシャーナイ。

こちらのサイトで様々な企業や組織のインデント規約を調べたり、アンケートを取っていたりするのでより詳しく知りたい方はそちらをご覧ください。
2023年の記事なので少し古いかもですけどね。

今どきのJavaScriptで使われているインデント規約まとめ - ICS MEDIA

とまあ概ね模範的でキレイなHTML文書ですが、どうしても少し気になる点があります。
トップページにある画像のaltが全てalt="..."となっているところと、<tag />みたいな自己完結型タグが混じっているところです。

予め書きますが、僕個人が気になるだけでダメ出しするつもりはありません。
あくまで僕が作るとしたらやらないってだけで。

もし見たくないのならこちらをクリックしてください。
本当に結構強めの口調で書いてしまったので、苦手な方は飛ばすことを推奨します。

まずaltが全てalt="..."となっている点ですが、軽く調べた感じトップページだけaltがalt="..."と画像を説明する文章がありません。
ほんの一部のページしか確認してませんが、中村杯艦船模擬戦2025や茶番の特設サイトなど比較的新しいページではしっかり画像にあったaltが指定されてます。

そう、比較的新しいページには問題はありません。
かつてはaltの付け方を知らなかったのかもしれませんが、おそらく今の中丸・中村造船さんは正しいaltの付け方を知っているのでしょう。

だからこそ思うのです。
何故よりによってサイトの顔ともいえるトップページがこうなっているのかと。

正直alt属性を完璧に使いこなすことは難しいと思います。
自分自身、完全に正しいと胸を張って言えるわけではありません。

今回、改めてalt属性について調べてきました。
まず結論から書くとalt属性はHTML Living Standardを策定してるWHATWGの公開してるHTML Standardに従って書けです。

そりゃHTMLを策定してるところの情報が最も正しいですよね。
身も蓋もありませんが一次情報が一番正しいです。
公式が最大手とはまさにこのこと。

とはいえ流石にこれで終わるのはアレなのでalt="..."の問題を書きましょう。
ちなみにaltが間違ってるか否かでSEOに影響はないそうです。
あくまで又聞きですがね。

また長くなり過ぎたので解説を飛ばせるようにしました。
もし飛ばしたい方はこちらをクリックしてください。

alt属性の状態は大きく3パターンあります。
普通に代替テキストを書く、alt=""とaltの属性値を書かない、そして根本的にalt属性そのものを書かない3パターンです。

ソースコードにするとこんな感じですかね。

<!--普通に代替テキストを書くパターン-->
<img src="URL" alt="画像の説明">

<!--altは書くがテキストは無いパターン-->
<img src="URL" alt="">

<!--そもそもaltを書かないパターン-->
<img src="URL">

それではそれぞれの説明をしましょうか。

まずaltに代替テキストを入れるパターンですが、基本的にはこれが良いでしょう。
どういうテキストを入れるかは少々難しい話になりますが、テキストを入れられるのであるなら可能な限り入れるべきですね。

厳密には細かい仕様は色々ありますが、端的に言えば置き換えた時に意味が変わらないようにしてくださいってことですね。
例えば会社のロゴにalt="会社ロゴ"ではなくalt="○○株式会社"と書くようにと書かれています。

次にaltのテキストが無いパターンですが、これは画像の説明が不要な場合に使います。
例えばこういう使い方をする場合ですね。

ページのタイトル

これは画像のサンプルです。
テキストは特に意味ありません。

<h1>ページのタイトル</h1>
<img src="../images/25_10_04.svg" width="80" alt="">
<p>これは画像のサンプルです。<br>テキストは特に意味ありません。</p>

ページのタイトルの下に薄紫のギザギザの画像があります。
このような装飾的な画像にはaltにテキストを入れてはいけません。

ここで注意したいのがaltにテキストを入れなくても良いではなく、テキストを入れてはいけないと決められている点です。
altはよく可能な限り書けって言われますが、書くなと言われることは少ないので知らない人も多いでしょう。

今回のサンプルのような事例は4.8.4.4.8 A purely decorative image that doesn't add any informationのパターンに該当するでしょう。
翻訳のせいで誤った表現になっている可能性も否めませんがね。

altが空の画像で有名なものを上げるとするならYouTubeのサムネイルでしょう。
この場合は4.8.4.4.6 A graphical representation of some of the surrounding textとかになるのかな？

ちなみに=""を省いて単にaltと省略することも可能です。
こっちの方がすっきりするので、実際に使うとしたらこちらの方が良いでしょう。

次にaltがそもそもないパターンですが、代替テキストを入れるべきであるものの何かしらの理由によりそれができない場合に使われます。
例えば町のライブカメラとかで自動的に更新される場合や、SNSなどでユーザーが画像の代替テキストを用意しなかった場合などでしょう。

変わった条件だと作成者自身が画像が何を表しているのか知らない場合もあります。
ちなみに例は「盲目の写真家がブログで写真を共有する」と書かれてました。

なお本当はもっと条件が厳しいですが、今回の話にはあまり関係ないので省きます。
ちなみにaltが無い画像として有名なものは阿部寛のホームページの阿部寛さんの画像などがあります。
まあ正しい使い方ではないと思いますが。

なお実際のSNSではAIを使っているのか、altがない画像を見かけることはありません。
X(旧Twitter)ではインプレッションが少ない画像や古い画像はalt="画像"となっているのを結構見かけますが、これはこれで問題がありそうですね。

これを踏まえたうえでalt="..."の問題点を上げると、代替テキストが代替テキストとして機能していないという点です。
alt="..."となっている画像はすべてスライドに使われている画像であり、キャプションが書かれているため必ずしも必要というわけではありません。

ですが説明が不要な画像に書くべきはalt=""であり、alt="..."ではありません。
...という意味を持たない文字列ではなく、真の意味で空の文字列が必要なのです。

altを書くなら書く、書かないなら書かない。
そうあるべきところにalt="..."と、空ではないが意味もないaltが設定されてます。

また書きそびれましたがalt属性を持たない画像もあります。
必ずしも代替テキストが必要ではありませんが、少なくともalt=""は書くべきでしょう。

余談ですが公式の文書は長くて大変なのでもう少し詳しく知りたい方にはこちらのサイトが良いかと思います。
この2つは情報源がしっかりしているので大きな間違いは無いでしょう。

alt属性なしとalt=""で意味が違う
お前らはまだ img タグの alt 属性の付け方を間違っている

長くなりましたが次は<tag />みたいになっている件について書きます。
これが気になった理由は、単純に今は使われていない記法だからです。

HTML Living Standardには空要素という、開始タグしかない要素があります。
例えばbr、img、meta、linkはよく使いますね。

またまた長くなり過ぎたので解説を飛ばせるようにしました。
もし飛ばしたい方はこちらをクリックしてください。
いい加減自制しろよ自分。

Void element （空要素） - MDN Web Docs 用語集 | MDN

そしてこれらのタグを用いる時、開始タグの末尾にスラッシュを付けるパターンがあります。
この開始タグの末尾にスラッシュを書いたものを「自己完結型タグ」と呼ぶそうです。

自己完結型タグ

<!--普通のタグ-->
<p>開始タグと終了タグのある一般的なタグです。</p>

<!--開始タグしかない空要素-->
<br>

<!--末尾にスラッシュがある自己完結型タグ-->
<br />

たまに見かける自己完結型タグですが、実はHTMLに自己完結型タグは存在しません。
自己完結型タグはかつて存在したXHTMLや様々なところで使われるXML、ベクター画像の代表格であるSVGなどには存在します。
これらのマークアップ言語で空要素を扱う時は、末尾にスラッシュが絶対に必須です。

しかしながらHTMLに自己完結型タグは存在しません。
<tag />という書き方はHTMLに存在しないのです。

これはXHTMLやSVGなどはXMLから派生した言語であるのに対し、HTMLはXMLの祖先にあたるSGMLを元に開発されたからです。
<tag />はXMLから追加されたものであり、HTMLの元となったSGMLにはないので自ずとHTMLにもありません。

ちなみにSGMLを応用していたのはHTML4系までで、HTML5やHTML Living StandardはSGMLの応用ではないそうです。
まあHTML4系、XHTML、HTML5と大きく変わってきたので当然なのかもですね。

とはいえWordPressなどのツールでは互換性や読み取りやすくするために、あえて自己完結型タグを用いる場合があります。
YouTubeやAmazonなど、大手のサイトでも自己完結型タグが見られます。

意外なところでは、先ほどのHTML Living Standardを策定してるWHATWGが公開してるaltの使い方を説明しているページにもあります。
HTMLを策定しているところにすらあるので、完璧になくすのはかなり難しいでしょう。

とはいえあくまで一定の法則で使用していたり、十数万文字以上の長いソースコードの中に見逃したのか残っていたりとそれなりに納得できる理由があります。
HTMLだけで十数万文字あれば、大なり小なりミスが出るでしょう。

しかし中村のマインクラフト造船では同じmetaでも末尾のスラッシュがバラバラと、法則性が感じられません。
また個人サイトとしては比較的ページ数が多いですが、1ページあたりの文字数は極端に多くありません。

そしてよりによってこれがトップページで起きてるのが気になります！
正直トップページで起きてなければここまで気にならなかったでしょう。

トップページはサイトの顔とも言えるページであり、サイトの中でもかなり重要でしょう。
そんなトップページで！なんで！こんな古めかしいコードがあるのかと！

特に中丸・中村造船さんはハイテク技術を前面に押し出している方であり、技術の最先端を突き進んでいる印象です。
そんな方だからこそ、XHTMLという大昔に使われていたものの断片が気になります。

とまあ色々言いましたが、この2点以外に関しては本当に優秀です。
ソースコードも非常に見やすく、容易にコンテンツの追加や修正が可能に見えます。

WordPressなど自動で作るツールが増えた昨今、このように余計なものがないサイトは少なく非常に貴重です。
未来の開発者を育てるためにも、このようなサイトは価値があるでしょう。

とまあソースコードを見てきましたが、検索に出ない原因は見つかりませんでした。
というわけで次の調査に移行しましょう。
蛇足が長すぎて本題を忘れてる方はいませんか？(笑)

そんなわけで次の調査を行おうとしましたが、その前に中村さん自身が調査したブログに手掛かりがないかと改めて読むことにしました。
NNZ Third blog – Just another WordPress site

すると見落としていた情報を見つけました。
サーバーがGitHub Pagesであるという情報。

最初読んだ時は文量が多いこともあり、かなり文字を飛ばしながら読んでました。
いわゆる斜め読みをしていたというわけです。

今回は疲れていたので休憩がてらに読んでいたところ発見しました。
こんな情報を見逃すなんて……。

とまあサーバーがGitHub Pagesということが分かりましたが、ドメインからてっきりXServer系かと思って調べてなかったサーバーについて調べる必要が出てきました。
XServerであれば障害がないことは分かりますが、別のサーバーとなると話は別です。

サーバーのトラブルでGoogleのbotがアクセスできないという可能性も考えられます。
まあGitHubに限ってそんな意味不明なトラブルは無いと思いますがね(笑)

というわけでGitHub Pagesの障害について調べましたが、有力な情報は無かったです。
軽微な障害は多々ありましたが、こんな大きなトラブルは見つかりませんでした。

というかサーバーが違うnnz-blogでも起きてるので違うのは分かりきってましたけどね。
もしサーバーが原因ならなんで違うサーバーでも起きてるんだよって話です。

行き詰まってきたのでWappalyzerというサイトに使われている情報を取得できる拡張機能を使いより詳しく調べることにしました。
この拡張機能によってjsDelivrやFastlyを使っていることが分かったものの依然として、原因の特定には至りませんでした。

まあCDNの知識はほぼないので問題があっても気づけないと思いますが……。
現状アクセス数がそこまで多くないですし、CDNが無くてもなんとかなるんですよね(笑)
XアクセラレータもCDNの一種らしいですが、サーバーの一部であり他のCDNとは毛色が異なります。

あと怪しいところで言えば、ページの一部をJavaScriptで追加してるところとかありますが、おそらくこれも原因とはなりえないでしょう。
HTMLの一部をそのままJSで追加するのは少し珍しいですが、JSによるタグの記述は現代のサイトでは当たり前に行われています。

うちのサイトでもスライダーのライブラリで一部のタグが追加されてますし、それこそ自分で書いたimportant.jsでほぼ同じことをやっています。
うちのサイトが表示される以上、JSでHTMLを差し込むのが原因とは思えません。

ちなみに中村のマインクラフト造船ではヘッダーをJSで書いてますが、僕の北上ゆま 公式HPでは個別のページにそれぞれ書き、この隠しサイトはiframeで流用しています。
今ならiframeで共有しますが当時はそんな技術持ってなかったんですよね～。

はじめての日記や近代化改修2でも少し触れましたが、僕がiframeを使ったのはYouTubeの埋め込みを除くとこの隠しサイトが初めてです。
なのでそれよりも前に作った表のサイトでは使われてないんですよね。

とまあ行き詰まったので、軽い気持ちでLighthouseを走らせてみました。
何か新しい情報が得られるかと思って。

すると手がかりとなる重要な情報が出てきました。

LighthouseによるとGooglebotのクロールが禁止されているそうです。
これは重要な手がかりと言えるでしょう。

追記です。
これ以降しばらく情報を誤解したことにより無意味な情報収集を行ってました。

そのためこれ以降はしばらく無意味な文章が続きます。
そのためこちらから飛ばすことを強くおすすめします。

なお今回の目的と無関係だっただけで情報自体は有益なので残します。
集めた情報を知りたい方や、誤った情報に踊らされるのを見たい方は続きをどうぞ。

今見ると「これは重要な手がかりと言えるでしょう。」は恥ずかしいですね(笑)
完全に無意味というわけではありませんが、今回の手がかりにはなりませんでした。

クローラーをブロックする方法は3つ存在します。
metaにNOINDEXを書く方法、robots.txtで巡回を禁止する方法、.htaccessで根本的にアクセスをブロックする方法の3つです。

NOINDEXを書く方法はこのサイトでも用いてるため真っ先に確認しましたが、それ以外の方法は完全に頭から抜け落ちてました。
これは盲点です。

ちなみにnginxの設定の設定を変更してブロックをする方法もありますが、GitHub Pagesが使われているので今回は調べません。
というか調べられるんですかね……。

.htaccessは僕も使っているのでまず.htaccessから調べてみることにしました。
しかしリダイレクトの設定があるのみでブロックの記述はありませんでした。

ところでGitHub Pagesで.htaccessって使えるんですね。
.htaccessって本来Apacheのファイルなんですが、何で動いてるのか不明なGitHub Pagesでも使えるんですね。
GitHub PagesってApacheで動いてるのかな？

ちなみに僕が使っているシンフリーサーバーはnginxで動いてるそうですが、例外的に.htaccessが使えるようになっています。
このことについては2024年03月30日　nginxで少し触れてましたね。
今気づいたけどサーバー移行するのに大変だったことを書くって言ってるのに書いてないじゃん(笑)

.htaccessには問題なかったので続いてrobots.txtを調べようと思いましたが、ここで一つの問題が生じます。
それは僕がrobots.txtのことについて何も知らないということ。

実は僕、URLの正規化のために.htaccessは勉強しましたが、robots.txtは別にいらないでしょって思って触ったことないんですよね。
手動で登録すれば良いだけですし、概要欄やX(旧Twitter)からのアクセスが殆どで、検索から来る方が全くいないからです。

現状、最初から検索に出すつもりではない簡易版と隠しサイトと一部の隠しページ以外の全てのページはGoogleのインデックスに手動で登録済みです。
にもかかわらず9月の445名いる訪問者のうち検索で来たのは1名のみと、検索サイト以外からの流入が殆どです。

こんな状況ではわざわざrobots.txtを学ぼうという意欲は沸きません。
robots.txtを学ぶくらいなら、最後の未完成ページであるプロフィールを書くべきでしょう。
まあそれすらできる状況じゃないんですがね。

ですが今はrobots.txtの知識が必要です。
試しに一回見ましたが夜遅かったので時間に余裕がある時に、じっくりと問題があるかを探ることにしました。

そのはずでした。
しかし数日経って再度アクセスしたところ、robots.txtの内容が変わってました。

他人のコードを無断で転載するのは憚られますが、あまりにも短いですし再度変更されるかもしれないのでここに記します。
これは2025年10月03日に確認した時のrobots.txtです。

Sitemap: https://zosen.nnz-design.com/sitemap.xml
User-agent: Googlebot

うん。
シンプルですね。

試しにこの状態で再度Lighthouseを走らせたところ、例の警告は消えていました。
この時点で僕はrobots.txtの消えた記述が原因だと確信します。

よくよく考えてみれば当たり前ですよね。
ソースコードが変わることくらい。

当事者である中村さんが改善しようとするのは自然な流れです。
僕が調べる以上に原因を知りたがるのは当然です。

ですが困りました。
原因がよくわからないまま消えたのでは困ります。

どういう仕組みでブロックされていたか分かりませんし、偶然同時に変更されただけで原因が別に存在する可能性もあります。
それこそ例のブログに書いてあるようにBANされていた可能性も考えられます。

一応過去のrobots.txtを見るために色々やってみました。
キャッシュから復元してみたり、C丸ごとやっているバックアップからChromeのキャッシュをぶっこ抜いて復元を試みましたが残念ながら不可能でした。

それもそのはずrobots.txtへアクセスしたのは9月26日20時09分。
その日のバックアップを行ったのは20時03分で、ほぼ丸一日後の27日19時00分にやったバックアップには残ってませんでした。
ちなみに26日の時間が中途半端なのはその日の日記で書いた出来事が影響してたり。

フルスクラッチした小規模な個人運営のサイトという非常に似た状況のサイトを運営する身として謎を謎のまま放置するわけにはいきません。
そこで記憶を頼りに問題が発生していたrobots.txtを再現してみることにしました。

この状況で原因を確かめる最も確実な方法。
それは人為的に同じ状況を起こすほかにありません。

Sitemap: https://zosen.nnz-design.com/sitemap.xml

User-agent: Googlebot
Disallow: /

こちらが記憶を頼りに再現したコードです。
今現在のコードとの大きな違いはDisallow: /の有無とSitemapの下の改行です。

正直改行に関しては記憶があやふやですが、Disallow: /があったのは確かです。
Disallow: /じゃないかもしれませんが、Disallowは確実にありました。

調べたところDisallowというルール(robots.txtでは各行の先頭に付くコレをルールと呼ぶらしい)はクロールを禁止するディレクトリやページを指定するルールみたいです。
例えばDisallow: /nocrawl/と記述した場合、クローラーはnocrawlとその配下全てへのアクセスが禁止されるそうです。

robots.txt の書き方、設定と送信 | Google 検索セントラル

別のルールと見間違えた可能性も考えられますが、先頭にDがあったこと、小文字のLが2回連続していたこと、Sitemapとほぼ同じ文字数であることは間違いないです。
そしてこの条件に当てはまるのはDisallowただ一つです。

robots.txtの書き方を知っているならともかく、robots.txtについて全く知らない中Disallowと書けたのなら記憶の混同も考えにくいでしょう。
大変恥ずかしい話ですがDisallowという英単語があるということすら知りませんでした。
Di+SallowじゃなくDis+Allowなんですね。

そんな状態でコレを書いたということはDisallowがあったのは間違いないでしょう。
ディレクトリが違う可能性は全然ありますけどね。

とまあDisallowがあったのは間違いないですが、この記憶を頼りに再現したコードは一体どんな挙動をするコードなのでしょうか。
robots.txtの構文とにらめっこしながら調べたところ、この再現のコードはGooglebotというクローラーからのアクセスを全て禁止するというものでした。

そりゃGoogle検索に載らないわけだ。
Googleのクローラーを禁止にしてたらGoogleの検索に載りませんよね。

というわけで僕のホームページにも同じrobots.txtを設置したいと思います。
Sitemapが無いので一番上の行は削除しましたが、概ね同じrobots.txtです。

再現したrobots.txtの設置後、Lighthouseを走らせたところ同じ警告が出ました。
参考までに計測結果を公開するので気になった方はご覧ください。

HTML形式とJSON形式の2つがあったので両方zipに入れときます。
Gist形式で保存というのもありましたが、僕がGitHubのアカウントを持っていないので保存できませんでした。
プログラマーならGitHubのアカウント作れよっていうね。

ちなみにモバイルでの測定結果がデスクトップより低いのは、サイト自体が元々モバイルを想定して作っていなかったからです。
当時はとにかくホームページとしての体裁を整えるのに必死だったので。

過去のアーカイブ見たらわかりますが、デザイン自体はそこまで変わってないのでそろそろ根本から弄りたいと思っていたり。
まだ未完成なのにね！
サグラダ・ファミリアかよ。

Lighthouseでの確認は行いましたが、流石にGoogle Search Consoleでインデックスに登録する作業はやりませんでした。
やらなかった理由はアクセス数が少ないとはいえ本番の環境であることと、インデックスの登録に時間がかかるからです。

一応隠しサイトのトップページからNOINDEXを外して検証を行ってみたいと思います。
追加の検証が終わり次第、この下に追記したいと思います。

追記です。
ちょっと問題が発生しました。

robots.txtを置いてインデックスに登録しようとしたところ、robots.txtの存在が原因で登録できませんでした。

そこでrobots.txtを削除して再度申請してみましたが、robots.txtがまだあると言われ登録できませんでした。
登録されていたものが登録されなくなったというのを再現したいのにこれでは意味がありません。

ですがここからわかることはGoogle Search Consoleは1度読み込んだrobots.txtをしばらく保持しているということです。
もしかしたらそれが原因でインデックスに登録されなかったりして。

とりあえずしばらくしてからもう一度やりたいと思います。
その時は再び追記します。

また追記します。
インデックスに登録できました。

robots.txtがある状態で申請してから1日と半日後、再度申請したら通りました。
どうやら短期間に何度も申請できないようになってるみたいですね。

時間の関係で1日と半日経ってしまいましたが、もしかしたらもう少し早くても申請が通るかもしれません。
まあ今回の主題ではないので調査は省きますが。

とりあえず検証を行う前段階の作業が完了したので再びrobots.txtを設置します。
これで上手く行けばいいんですがね～。

またまた追記です。
結果から言うと今回僕が気づいたのはrobots.txtで全てブロックしたからだと思われますが「クロール済み - インデックス未登録」になった原因はrobots.txtではなさそうです。

ここ数日、中村のマインクラフト造船が検索しても全くでなかった原因はrobots.txtで間違いありません。
ですがrobots.txtでクロールを禁止しても「クロール済み - インデックス未登録」ではなく「robots.txt によりブロックされました」になることがわかりました。

robots.txtが原因だと思って色々考察しましたが、全部無意味でしたね。
直近のブログでrobots.txtに触れてなかったですし、これだと思いましたが違いましたね。

というわけでrobots.txtが原因だと思ってた時の考察は完全に無意味となりましたが、流石に全文消すのはもったいないので残しときます。
下の三角マークをクリックすると考察を開くことができます。

まさか自分が誤った情報に踊らされるなんてね。
焦っている時は盲目的になりがちと聞きますが、まさか自分がそうなるなんてね。

#####rewrite#####
RewriteEngine on
RewriteCond %{THE_REQUEST} ^.*/index\.html
RewriteRule ^(.*)index.html$ https://kitakamiyuma.com/$1 [R=301,L]

RewriteCond %{HTTP_HOST} ^www\.kitakamiyuma\.com$
RewriteRule ^(.*)$ https://kitakamiyuma.com/$1 [R=301,L]

RewriteCond %{HTTPS} off
RewriteCond %{REQUEST_URI} !(^/lite/|^/images/lite/|^/css/lite/|^.*/important_lite\.js)
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

RewriteCond %{HTTPS} on
RewriteCond %{REQUEST_URI} ^/lite/|^/images/lite/|^/css/lite/|^.*/important_lite\.js
RewriteRule ^(.*)$ http://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
#####end:rewrite#####

というわけで振出しに戻りました。
えぇ、完全に振出しに戻りました。

ですが完全に無意味だったかと言われたらそうではありません。
少なくとも「robots.txt によりブロックされました」と「クロール済み - インデックス未登録」は違うとわかりました。

問題との関係がわからないのと問題と関係がないとでは天と地ほどの差があります。
関係がないということは、これ以上そこを調べなくて良いということを意味しますから。

というわけで盛大な勘違いをしていたわけですが、どうやら僕のホームページにも「クロール済み - インデックス未登録」があることに気が付きました。
「クロール済み - インデックス未登録」って一体どこで見るんだろうなんて考えてましたが、根本的に見る場所が違いましたね。

僕のホームページでインデックス未登録なのは全部で5つ。
そのうち3つは画像なので、純粋なWebページは2つです。

• https://kitakamiyuma.com/news/r05_07_04_01/
• https://kitakamiyuma.com/links/youtube/

こちらがそのインデックス未登録のページです。
逆に言えばこれとmetaで禁止しているページ以外は全て登録済みだということです。

ちなみにmetaで禁止してるのは隠しサイトの全てと簡易版の全てと表の一部ページです。
意外にmetaで禁止しているページが多いんですよね。

今回の問題である「クロール済み - インデックス未登録」が僕のサイトにもありました。
しかしながら中丸・中村造船さんの状態とは異なります。

この2つのページに共通することは、あからさまに情報が少ないところです。
この2つは壁の染みを見たほうが、より多くの情報を得れるくらいには情報がないです。

インデックスが未登録になる原因は色々ありますが、その中の1つに低品質なコンテンツがあります。
この2つのページはまさに情報量の少ない低品質なコンテンツと言えるでしょう。

対して中村のマインクラフト造船の問題は、情報量が割と多いページまで「クロール済み - インデックス未登録」になることです。
僕のサイトで起きてる「クロール済み - インデックス未登録」とはわけが違います。

僕のサイトの例は全く参考になりません。
これは困った……。

とまあ再び行き詰まりそうになって困っていたところ、robots.txtの問題が解決したなら全部じゃないにしろ検索に出るのではと思いました。
というわけでGoogleで「site:https://zosen.nnz-design.com」と検索してみました。

この検索結果を見ていくつか気になった点があります。
僕が真っ先に気になったのは「中村のマインクラフト造船」が2つある点です。

詳しく見たところ、上と下の違いはindex.htmlの有無でした。
上にはindex.htmlが無く下にはindex.htmlがあります。

これを見て思った事が1つあります。
もしかして正規化されてない？

詳しく調べたところhttpでアクセスしたらhttpsに飛ぶ機能とwww.nnz-design.comにアクセスしたらnnz-design.comに飛ぶ機能はありました。
しかしindex.htmlの有無を統一する正規化は行われていませんでした。

.htaccessを見たところ、httpで来たものをhttpsにする記述は見られなかったので、おそらくGitHub Pagesの機能で行っていると思われます。
ちなみに僕の使うシンフリーサーバーもhttpsに固定したり、wwwありやなしに転送する機能があるものの、.htaccessに自動で変更を行うタイプです。

まあ僕はその機能は使わず手動で.htaccessを変更しましたけどね(笑)
まあ僕のサイトが特殊ゆえに、手動で設定するしかなかったんですがね。

とまあ正規化がされてないことがわかりましたが、とある可能性が脳裏をよぎりました。
もしかしてindex.htmlの有無がバラバラになっているのでは？と。

調べてみるとHTMLファイルに関してはindex.htmlが付いたリンクで統一されてました。
index.htmlが無いリンクもあるかもしれませんが、僕が確認した範囲ではありませんでした。

対してsitemap.xmlでは全てindex.htmlが付いていないリンクで統一されてました。
この食い違いは大きいでしょう。

クローラーがrobots.txtで指定されたsitemap.xmlを使いサイト内を巡回する。
しかしサイト内はindex.htmlありで統一されてるので、index.htmlが無いリンクは内部リンクがされていないと判断される。

またindex.htmlありとなしが別物として評価されることによって、コンテンツが重複していると判断された可能性もあるでしょう。
なにせSSLの有無とwwwの有無だけで別のページ扱いになりますからね。

それ抜きに同じコンテンツへ異なるURLからアクセスできる状態はあまり良くないです。
詳しい人ならともかく、詳しくない人は検索で同じページが複数出たら混乱するでしょう。

正規化について調べたところ、このようなページを見つけました。
これを見た感じ、index.html有無で評価が分散する現状は良くないでしょう。

URL 正規化とは何か | Google 検索セントラル
rel="canonical" などを利用して正規ページを指定する方法 | Google 検索セントラル

正規化については正直面倒ですし難しいです。
僕も正規化について勘違いしていて、少しトラブルが起きたことありますし。

せっかくなので僕がやった失敗を紹介します。
僕のやった失敗は、URLの末尾にスラッシュを付けるべきなのに付けてなかったことです。

リンク集 - 北上ゆま 公式HPを例に説明しましょう。
ちなみにリンク集 - 北上ゆま 公式HPはトップページの次に古いページだったり。

このページはkitakamiyuma.comというサーバーのlinksというディレクトリにあります。
正確にはlinksの中にある「index.html」というファイルがページの本体です。

このページへ省略せずアクセスする場合、このようなURLになります。
なお通信はHTTPSを用いるものとします。

https://kitakamiyuma.com/links/index.html

ただし実際はここまで長くなくありません。
特にindex.htmlはデフォルトドキュメントという特殊なファイルなので省略できます。

https://kitakamiyuma.com/links/

index.htmlを省く書き方としてはこれが正しい書き方です。
ですが僕は勘違いしていました。

https://kitakamiyuma.com/links

これがその間違った書き方です。
かつて僕はこのようにリンクを書いてました。

これでもhttps://kitakamiyuma.com/links/へ勝手にリダイレクトされますし、かつてはGoogle Search Consoleを使ってなかったのでこれでサイトとして成り立ってました。
当時は1byteでも削ろうと躍起になってましたからね。

しかしGoogle Search Consoleを使ったところ、問題が起きました。
「ページにリダイレクトがあります」が大量に発生したんです。

当時は驚きましたね。
https://kitakamiyuma.com/linksとhttps://kitakamiyuma.com/links/は別扱いかよって。

よくよく考えれば違いますよね。
kitakamiyuma.com/links/はindex.htmlを省略しただけで、linkってファイルではありません。

あくまでindex.htmlを省略したものなのでkitakamiyuma.com/links/が正しい。
今ならそれがわかります。

ただこの件からGoogle Search Consoleは1文字でも違うと、異なるページとして扱うことがわかりました。
そのためindex.htmlの有無で異なる扱いになっていることも推測できます。

.htaccessを使えば簡単にリダイレクトさせることができるのでやってみると良いかも。
少なくとも僕のサイトのように、一部だけhttpにするみたいな変なことをしない限り、正規化するのは簡単でしょう。

ちなみに僕のサイトの正規化はこうなっています。
なんか色々と凄いことになってますね(笑)

#####rewrite#####
RewriteEngine on
RewriteCond %{THE_REQUEST} ^.*/index\.html
RewriteRule ^(.*)index.html$ https://kitakamiyuma.com/$1 [R=301,L]

RewriteCond %{HTTP_HOST} ^www\.kitakamiyuma\.com$
RewriteRule ^(.*)$ https://kitakamiyuma.com/$1 [R=301,L]

RewriteCond %{HTTPS} off
RewriteCond %{REQUEST_URI} !(^/lite/|^/images/lite/|^/css/lite/|^.*/important_lite\.js)
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

RewriteCond %{HTTPS} on
RewriteCond %{REQUEST_URI} ^/lite/|^/images/lite/|^/css/lite/|^.*/important_lite\.js
RewriteRule ^(.*)$ http://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
#####end:rewrite#####

一つだけ疑問が残るのは、nnz-blogでは正規化が行われているのがわかりました。
中村のマインクラフト造船が表示されない理由にはなりますがnnz-blogが表示されない理由としては少し不十分です。

NNZ Third blogによるとnnz-blogもインデックスに登録されないそうです。
あくまで内部リンクの問題は一つの要因に過ぎないのかもしれません。

正規化はこれくらいで終わりましょうか。
では次に気になったことに行きましょう。

次に気になったのはサイト名が一部「GitHub」になっている点です。
Google検索におけるサイト名は、faviconの横にある「nnz-design.com」や「GitHub」になってるところです。

僕は面倒なので「kitakamiyuma.com」のままですが、「GitHub」は違和感を感じます。
中村のマインクラフト造船であってGitHubではありませんから。

というわけでサイト名がGitHubになっていた有馬・中村級戦艦 - 中村のマインクラフトを調べてみることにしました。
ちなみにGitHubになっていた中で一番上の中村について - 中村のマインクラフトじゃないのは検索結果によってGitHubになったりnnz-design.comになったり不安定だからです。

というわけでソースを確認したんですがそもそも有馬・中村級戦艦 - 中村のマインクラフトという名前のページではありませんでした。
titleタグによると有馬・中村級戦艦｜砂式無線通信に対応した戦艦 - 中村のマインクラフトが正しいタイトルみたいです。

本題ではないので軽く流しますが、どうやら最近のGoogleは検索結果に出るタイトルを勝手に変更するみたいです。
軽くネットで検索したところ、このようなページが見つかりました。

Google 検索結果のタイトルリンクの変更 | Google 検索セントラル
Googleが6割以上のページのタイトルを勝手に書き換えて検索結果に表示 - GIGAZINE

どうやら長すぎたり短すぎるタイトルは勝手に変更されるみたいです。
僕のサイトではこのような現象が起きてなかったので驚きました。

サイト名とは無関係ですが、もしかしたらこれも影響してるのかもしれませんね。
まあ確証はありませんけど。

とまあ、GitHubが一体どこから来たのか調べてみました。
しかしその作業は難航することになりました。

そもそも「GitHub」という文字列がHTMLのソースやrobots.txt、sitemap.xmlの中に無いことは既に知っています。
トップページ以外にはある可能性は否定できませんでしたが、実際に見たところGitHubの文字列はありませんでした。

一体全体どこから「GitHub」がやってきたのか不思議でなりません。
GitHub Pagesは使われてますが、その法則なら僕のサイトはXServerになるはずです。

行き詰まったので一か八かいろんなところを見ることにしました。
するとこんなものが出てきました。

こちらはWindows 10のコマンドプロンプトです。
コマンドプロンプトでnslookupコマンドを実行してみました。

流石にIPアドレスは隠します。
nslookupをしたら普通に見れるので隠さなくても良い気がしますが、他人のサイトのアドレスを公開するのは流石に気が引けますからね。

zosen.nnz-design.comを調べたはずですが、nakamurazosen.github.ioになっています。
こんなことは初めてなので驚きました。
nslookupを使う頻度が少ないのもありますが。

Aliasesにzosen.nnz-design.comがありますが、Aliasesなんて初めて見ました。
調べたところ名前がDNSのAレコードで指定した本来のアドレスなのに対し、AliasesはCNAMEレコードで指定した別名だそうです。

nslookupのAliasesもDNSレコードのCNAMEも知らないので間違ってるかもしれません。
ですが僕はDNSレコードに怪しいところがあるのかと思い調べることにしました。

というわけでDNSレコードを調査することにしてみましたが、残念ながら手がかりになりそうな情報は得られませんでした。
DNSレコード確認ツールを使って調べたんですが、ツールの問題なのか調べ方が悪いのかGitHubという記述は見つかりませんでした。

多分ここだ！って思ったんですがね～。
うまく行かないですね。

Googleの公開する文書にサイト名の決め方が書いてないかと思い検索してみました。
検索したら出てきました。
ド忘れして調べてなかったのは内緒。

Google 検索でのサイト名 | Google 検索セントラル

うーん……。
チンプンカンプンですね。

ここを書いてるのが午前4時というのもありますが、そもそもSEOは僕の専門外です。
専門外なんですから理解するのに時間がかかります。

とりあえず頑張って読んでみましたが、構造化データというのが重要みたいですね。
ですが中村のマインクラフト造船には構造化データはなさそうです。

もしかしたらnakamurazosen.github.ioが影響しているかもしれませんね。
github.ioのサブドメインだからそのままGitHubってなってたりして(笑)

ここまで調べて原因が見つからないのは不本意ですが、これ以上調べてもサイト名がGItHubになる原因は出てこなさそうです。
今回の本題でもありませんし、これ以上の調査は諦めます。

というわけで「クロール済み - インデックス未登録」になる原因を調査してきました。
有力な説としてsitemap.xmlと内部リンクの食い違いと正規化が行われていないことが上げられますが、一応もっと他にないか調べてみます。

そういやsitemap.xmlを調べてる時にちょっと面白いものを見つけました。
ページ自体はあるものの内部リンクが行われてないページを3つ発見しました。

• 技術解説 - 中村のマインクラフト
• 視聴者様の意見にツッコミたいこと - 中村のマインクラフト
• 2023年までに登録者3万人 - 中村のマインクラフト

技術解説 - 中村のマインクラフトはおそらく何かしらやろうとした名残りと思われます。
ステータスコードは200なのに404のようなことが書かれているためソフト404ですね。

中村のマインクラフト造船は前にリニューアルを行っていますし、過去に使われてたページの名残りなのかもしれませんね。
ネットでもリアルでもリニューアルによって生まれた不要な空間を、壁などで塞ぎ隠すのはよくあることです。

もしくは何かやろうとしているのかもしれませんが、少なくとも僕にはわかりません。
中村さんなら技術の解説をやろうとしても不思議じゃないですけどね。

視聴者様の意見にツッコミたいこと - 中村のマインクラフトは視聴者のコメントに対する、中村さんの反応が書いてありました。
ページのスタイルはニュースと同じですが、ニュースとはURLの構造が少し異なります。

URLの中にdiaryという記述があることから日記のようなものだと推測できます。
人のこと言えませんが、誰しもサイトを作ったら日記を仕込みたくなるんですね(笑)

読んだ感想は「マジでそれな」です。
チャンネルの大小に関係なくこういうのはあるのだなと感じました(笑)

むしろ大きいからあるのかな？
見方によってはこのページも揚げ足取りをしてるように見えてしまいますし、そういう意味ではあまり見下すような発言を取れる立場ではありません。

ただ活動していると類似するコメントが何度も来ますし、そして似たようなことを思います。
このページを発見した時は思わず「あー……。」と思いましたね(笑)

2023年までに登録者3万人 - 中村のマインクラフトは本当に中村さんの個人的な日記といいますか何と言いますか……。
そんなページです。

ページのスタイルは視聴者様の意見にツッコミたいこと - 中村のマインクラフトと同じ。
日付を見た感じ視聴者様の意見にツッコミたいこと - 中村のマインクラフトの少し後に書かれた日記みたいです。

内容に関しては本当にただの日記。
クリエイターにありがちなスランプに関することが書かれた日記です。

過去の目標なのでわざわざ触れませんが、この中で脚本を書いてると書かれてます。
(当時は)ゆっくりなのにわざわざ脚本を用意していることに少し驚きました。

まあアレだけの規模をやるには脚本は必須なのかもしれませんね。
少し意外ですが納得感があります。

ちなみに僕は一切合切脚本を作らないタイプです。
動画編集ソフトで行き当たりばったりに作ってます。

まあ脚本を作るか作らないかの違いは最初から解説をメインにやっていたのか、元々実況をメインにやっていたのかの違いでしょう。
中村さんも少し実況を上げていたと記憶してますが、うちは軍事部の動画を上げる以前はずっと実況がメインでしたからね。

とまあ蛇足はこれくらいにして、他に有力な説を考えましょう。
ここからは物的証拠がない以上、完全な憶測になってしまいますが仮説はあればあるほど嬉しいですからね。

まずXServerドメインやGitHub Pages、Google検索そのものといった、サービスの不具合が重なって起きた説。
「robots.txtが原因だと思ってた頃の考察」と被る部分も多いですが、こういったサービスが不具合を起こし結果として「クロール済み - インデックス未登録」になった可能性。

robots.txtの件は中村さんが直接変更してた可能性が高いと結論付けましたが、これらのツールがGoogle検索に悪影響を与えた可能性は否定できません。
特にGitHub Pagesに関しては知らないことも多いため、もしかしたら何かしらのトラブルが起きた可能性もあります。

次に宇宙人が悪さをしている説。
もし宇宙人がいたとして、その宇宙人が地球を調査する一環でたまたま関与した可能性。

限りなく可能性は0に近いでしょう。
正直書いていて馬鹿馬鹿しいと思っています。

ですが何が起きているのか全く分かりません。
全く分からないということは宇宙人が原因という可能性を否定することはできないでしょう。

ただこれを確認する術はありません。
あるわけねぇだろそもそも宇宙人なんていないんだし。

次に宇宙から来る放射線の影響説。
あまりにもありえないと考えるかもしれませんが、マリオ64で宇宙線が原因と思われるバグがある以上は不可能ではないでしょう。

現代のコンピューターはかつてとは異なり、膨大なデータをやり取りします。
そのさなかで宇宙線に影響を受けてデータが狂ったとか。

次にイギリスが悪い説。
うん、とりあえずイギリスが悪いです。

この世の全ての問題は全てイギリスに行き着きます。
だからイギリスが悪いのです。

次に中村さんがストレスで多重人格となりもう一つの人格が悪さをしてる説。
要するに多重人格ですね。

中村さんほどになれば何かと悩ましいことが出てくるでしょう。
当然、ストレスが蓄積していきます。

その結果中村造船さんの精神が崩壊して、中村造船さんの人格とダーク中村造船さんの人格に分かれたとか……。
もし多重人格となっているのだとするなら、robots.txtでGoogleのbotをブロックしていた件がNNZ Third blogに書いていないことへの辻津が合います。

それに2023年までに登録者3万人 - 中村のマインクラフトという、過去にストレスがかかっていたことを示唆するページ。
これもこの説を補強させます。

流石にトンチキ過ぎるって？
これを書いてる人が多分一番せいじょう正常じゃないと思うので大丈夫です。

次は人工地震が原因説。
人工地震がGoogleのインデックスを登録をサーバーするところに発生したことにより、中村のマインクラフト造船のデータが破損した可能性です。

人工地震を起こすこと自体は不可能ではありません。
人工地震は災害系の陰謀論にありがちですが、規模はともかく人工的に地震を起こすことは不可能ではありません。

そこでGoogleを狙った攻撃がたまたた中村のマインクラフト造船に影響を与えた。
その可能性があるくないですか？

人工地震はありえないって？
宇宙人よりはよっほどまともやろ！

次は中村さんの飼っている動物がキーボードの上を歩き偶然Googleをハッキングした説。
要するにペットですね。

ペットが原因のトラブルって意外と多いですからね～。
ペットがやらかした可能性を考慮しないのは問題があるでしょう。

実際に起きたトラブルでは喋る鳥がアレクサで誤って物を注文することや、猫がキーボードの上に座ってしまいデータが消えてしまうなどを聞きますね。
中にはペットの魚にクレジットカードを無断で使われてしまうなんてのもあるそうです。

中村さんのペット(仮に亀を飼っているとしましょう)が知らぬ間にキーボードの上に乗ったとします。
そして適当にキーボードを打ち込んだ結果、たまたまGoogleをハッキングした。

そんなことが起きたかもしれません。
Googleの絶大な防御も亀の前では無いも同然です。

亀は何万年も防御に特化してきました。
そんな亀の前ではGoogleなんて赤子も同然でしょう。

亀の持つ潜在的な能力。
それによって破壊されたというのはいかがでしょうか。

この説の問題点は、中村さんがペットを飼っていなければそもそも成り立たないこと。
ペットが居なければペットがトラブルを起こすことはないでしょう。

次は安倍「やれ」Google「はい」説。
要するに森羅万象のことは全て元内閣総理大臣の安倍晋三さんが指示して行われているというゴリッゴリの陰謀論ですね。

流石にネタがブラックすぎるしもっとまともなことを言えよって？
宇宙人説よりはまともやろがい！

とまあ色々書いてきましたが、結論を書きたいと思います。
sitemap.xmlと内部リンクの食い違いと正規化が行われていないことが、「クロール済み - インデックス未登録」の原因であると考えました。

僕が今回の件について気づいたのはrobots.txtでGoogleのクローラーをブロックしたことにより、Google検索で全てのページが表示されなくなったのが原因でしょう。
ですがrobots.txtでブロックすると「クロール済み - インデックス未登録」にはならないため、問題を解決しようと中村さんが行ったことの1つだと判断しました。

このことが途中で発見したブログに書いてないのは気がかりですが、少なくとも「クロール済み - インデックス未登録」の原因にはなりえない。
僕はそう判断しました。

sitemap.xmlと内部リンクの食い違いが原因だと判断した理由は、Google Search Consoleが1文字でもURLが異なると違うページであると判定するのが理由です。
中村のマインクラフト造船ではindex.htmlの有無を統一するリダイレクトを設定しておらず、全く同じ内容を持つ2つのページと判断された可能性が高いです。

sitemap.xmlにはあるが内部リンクされてないページと、内部リンクされてるがsitemap.xmlに載ってないページの2つとしてGoogleのデータベースに入った。
結果として不完全な2つのページが互いに互いを重複するコンテンツと判断されてしまい、そして「クロール済み - インデックス未登録」になった。

またNNZ Third blogによると旧ドメイン、つまりGitHubのサブドメインを使ってた頃のページがインデックスに登録されているそうです。
Google Search Consoleにサブドメインだけ登録できるかわかりませんが、登録されているのが分かるというのであればサブドメインのみを確認できるのでしょう。

もしかしたらGoogleのクローラー上では旧ドメインのページもまだ存在することになっているのかもしれません。
現にコマンドプロンプトのnslookupによるとzosen.nnz-design.comはnakamurazosen.github.ioの別名となっており、あまり見たことない表示になっています。

index.htmlの有無により別ページ扱いされた上に、GitHubのサブドメインという強いドメインにあるページのコピーと判断されてしまった。
だから「クロール済み - インデックス未登録」となっている。

僕の過去の経験からしてこれが最もそれらしい理由。
僕はそう判断しました。

ですがこの説も完璧ではありません。
NNZ Third blogによるとnnz-blogもインデックスに登録されないそうです。

nnz-blogは中村のマインクラフト造船と異なり、全てindex.htmlのないページへリダイレクトを行うよう設定されています。
そのためnnz-blogにこの説は適応できません。

それに僕はGitHub PagesはおろかGitHubそのものについて全く扱ったことありません。
GitHubのGの字もないです。

他のトンチキな説よりはマシですが、絶対に正しいとも言えない。
所詮はその程度に過ぎません。

中村のマインクラフト造船からは404エラーや構文間違いなど、細かい問題も確認することができました。
しかしながら404エラーや構文エラーはそもそも検索に影響を及ぼしません。

たとえHTMLの書き方として滅茶苦茶だったり、ページの中で使ってる画像に404が多数あっても検索には出てくるそうです。
だからこの問題は今回の問題とは関係ありません。

XServerドメインやGitHub Pages、Google検索、サイトを作るのに使用するツール等、人間が関与した部分以外が悪い相乗効果を起こした可能性も考えました。
ですがそれらしい話を見つけることはできず、仮にあったとしてもそれをたった1人の人間が見つけ出すのは不可能でしょう。

これ以外にも多数の可能性を考えました。
Googleのバグをたまたま踏んだ説、クローラーにだけ別のデータが流れてる説、中村さんがツールの操作を間違えた説、宇宙からの放射線でメモリとかバグった説、フリーメイソンやイルミナティが関与した説、宇宙人が原因説、イギリスが悪い説、中村さんがストレスで多重人格となりもう一つの人格が悪さをしてる説、人工地震でピンポイントに壊された説、中村さんの家族が軍事部を良く思ってないあまりに起こした説、中村さんの飼っている動物がキーボードの上を歩き偶然Googleをハッキングした説、ゲッター線が関与した説、ちくわ大明神、オセアニアじゃあ常識なんだよ説、軍事部の亡霊説、寺院に機械があるから説、ミノフスキー粒子が干渉した説、ペングイーーんさんに監禁されていて外にSOSを出そうとしている説、タービンが回っているから大丈夫説、川の中に石があるから説、HAL 9000が干渉した説、安倍「やれ」Google「はい」説、などなど……。

現実的な可能性から、考えるだけでも馬鹿馬鹿しい可能性まで大真面目に考えました。
ですがsitemap.xmlと内部リンクの食い違いと正規化が行われていない以上に、それらしい可能性は見つかりませんでした。

ちなみにフリーメイソン説より後ろにある説は、全て馬鹿馬鹿しいと思った説です。
何だよイギリスが悪い説って。

とまあ色々考えてきましたが、原因は1つだけではないのかもしれません。
Googleにとって悪い要因が複数あって、それらが積み重なった結果「クロール済み - インデックス未登録」となるに至った。

そう考えることもできます。
その中でも最も大きな要因がsitemap.xmlと内部リンクの食い違いだと僕は思いました。

そもそも何でCNAMEレコードを使ってるんですかね。
普通にAレコードを使えばいい気がするんですが……。

というかCNAMEレコードって何ですか？
使ったことないので分からない……。

まあ何かしら理由があるのでしょう。
崇高なる中丸・中村大明神の考えは、我々凡人には理解できないのです。

これで解決できるかはわかりません。
これをやっても再び同じことが起こるかもしれませんし、起こらないかもしれない。

もしsitemap.xmlが原因じゃないなら、CNAMEレコードとかが原因かもですね。
なんとなくの「感」ですが。

「CNAMEレコード」って文字列を見てるとなーんか、嫌な予感がするんですよね。
CNAMEレコードが「うち、こんな使い方する物ちゃうで」って言ってくるような……。

まあ流石にこんなこと言い出したらオカルトですけどね(笑)
機械が話しかけてくるなんてどこのSFですか(笑)
この隠しサイト作った時、Aレコード認証したような……。

とりあえず今回の調査はこれにて一旦切り上げるとしましょう。
Kitakami Yuma Project.のyumaでした。