ディレクトリマップに書く項目一覧｜サイトの全体像を1枚に

URLの変更をともなうサイト移転について、検索エンジンを提供する側が公開している手順書には、旧アドレスと新アドレスの対応表を作るために調べる場所が5つ並べられています。サイトマップ、サーバーの記録または解析ソフトに残るアクセスの多いURL、管理画面に出る内部リンクと外部リンク、CMSが持っている全URLの一覧、そして最近1回以上アクセスのあったURLです。1か所を見れば全ページが分かる、とはどこにも書かれていません。「リニューアルの見積もりを頼まれて、自社サイトが何ページあるのか答えられませんでした」「制作会社から現行の構成表を出してくださいと言われ、探したのに社内のどこにもありません」——サイトを何年か運用した会社で、ほぼ必ず一度は起きる詰まりです。これは資料の作り忘れではありません。本当は、全ページを1枚に並べた表がないと、ページ単位の判断がすべて手探りになるのです。この記事では、ディレクトリマップ（サイト構成表、全ページ一覧とも呼ばれます）に何を書くのかを、列の決め方から集め方、判定の入れ方、更新を続ける形まで順に整理します。

ディレクトリマップは、全ページを1行ずつ並べた1枚の表

制作の現場では、ディレクトリマップは「Webサイトの全てのページに関する情報をまとめたもの」「サイトの設計図の役割を果たすもの」と説明されます。実体はきわめて素朴で、1行に1つのURLを置き、そのページについて知っておきたいことを横に並べた表です。呼び方は会社によって違い、サイト構成表、全ページ一覧、ページ一覧表などと呼ばれますが、指しているものは同じです。制作会社から「構成表をください」と言われたときに求められているのも、たいていこの表です。

よく混同されるのが、ページの親子関係を線でつないだ構成図です。あちらは関係を見るための図で、こちらは属性を持つ表です。違いは使い方に出ます。図は全体の形を一目で見るのに向いていますが、並べ替えも絞り込みもできないので、300ページを超えたあたりから判断の道具として使えなくなります。表であれば、更新日が古い順に並べる、担当が空欄の行だけ抜き出す、同じ語を狙っている行を集める、といった操作がその場でできます。ディレクトリマップが表の形をしているのは、見た目の都合ではなく、判断に使うためです。

では何の判断に使うのか。残す、直す、まとめる、消す、という4つのページ単位の判断です。この判断は、全件が1枚に並んでいない状態ではできません。並んでいないと、目についたページ、つまり普段よく見ているページから手を付けることになります。結果として、誰も見ていない古いページほど手つかずで残るという逆の並びになります。全体像を1枚にする目的は、この偏りをなくすことにあります。

検索向けの地図とも、来訪者向けの一覧とも別物

最初にここを切り分けておかないと、社内の会話がかみ合いません。サイトマップという言葉は、少なくとも3つの別物に使われています。1つ目は制作前に作る構成図、2つ目は来訪者向けに公開する一覧ページ、3つ目は検索エンジンに送るXMLサイトマップです。ディレクトリマップはこのどれでもなく、4つ目にあたる社内資料です。

XMLサイトマップは機械が読む地図です。仕様も決まっていて、1つのファイルにつき圧縮していない状態で50MB、URLの件数は50,000件が上限とされ、文字コードはUTF-8、書くURLは省略しない完全な形と定められています。さらに、更新頻度と優先度の指定は無視され、最終更新日は一貫して正確だと確認できる場合にのみ使われる、と公式に明記されています。つまり、担当者名も、残すか消すかの判定も、移行先も書けません。書く場所そのものが仕様に無いからです。

来訪者向けの一覧ページのほうは、公開する以上、載せるページを選びます。申込の完了画面や、終わったキャンペーンの特設ページは載せません。消したいページ、隠しているページ、忘れていたページが載っている唯一の表がディレクトリマップです。3つの中で、外に出さない前提で作られているのはこれだけで、だからこそ棚卸しに使えます。逆に言えば、この表を社外にそのまま渡すときは、見せてよい範囲を先に確認する必要があります。

作る場面は3つ。場面ごとに要る列が違う

ディレクトリマップを作る動機は、大きく3つに分かれます。リニューアルや移行の前、記事が増えすぎたときの棚卸し、そして制作会社への発注時です。この3つを同じ表で兼ねようとすると列が30を超え、誰も埋めなくなります。先に場面を決め、その場面で判断を変える列だけを立てます。

作る場面	この表で決めたいこと	必ず要る列	省いてよい列
リニューアル・移行の前	いま公開している頁を、どこへ持っていくか	URL、判定、移行先、親ページ	担当、最終更新日
増えすぎた記事の棚卸し	残すか、まとめるか、消すか	主題、最終更新日、流入の有無、判定	移行先、制作の進み具合
制作会社への発注	何ページ作るのか、誰が書くのか	ページ名、階層、担当、公開状態	既存のURL、流入の有無

表を見ると分かるとおり、3つの場面で重なる列は意外に少なく、URLとページ名のほかは場面ごとに入れ替わります。実務では1枚の表に列をすべて持たせたうえで、場面に応じて表示する列を切り替える形が扱いやすくなります。列を消すのではなく、隠す。こうしておけば、棚卸しで付けた判定を、半年後の移行のときにそのまま使えます。

見落としやすいのが、場面によって終わり方が違う点です。移行前の作成には公開日という締切があるので、多少荒くても終わります。棚卸しには締切がないため、完璧を目指すと終わりません。棚卸しで作るときは、はじめから対象を絞ります。たとえば公開から2年以上たっていて、直近1年の流入がない記事だけ、といった区切りです。全件を並べる作業と、全件を判定する作業は分けてよい。並べるのは全件、判定するのは絞った範囲、という進め方が現実的です。

最低限そろえる10の列

ここが記事の中心です。制作の現場で必須とされているのは、ページの管理番号、階層、ページ名称、URL、進み具合の5項目です。これは作るときの表なので、すでに公開しているサイトを整理する目的では足りません。棚卸しと移行に耐える最小構成として、次の10列を置きます。3列目には、その欄が空いたまま運用したときに実際に起きることを書きました。

列	書く内容	この列がないと起きること
管理番号	1行ごとに振る番号。第1階層は1、その下は1-1のように階層が読み取れる形にする	打ち合わせで「あのページ」としか呼べず、指示が別のページに伝わる
URL	先頭から末尾まで省略しない形で書く。表記のゆれを先にそろえる	他の一覧と突き合わせられず、同じページが何行にも分かれる
ページ名	画面上の見出し。社内での呼び名が違う場合は両方書く	行を探せず、行数が増えるほど表そのものが使われなくなる
階層	第1階層から数えた深さ	深いところに埋もれたページに、誰も気づかないまま残る
親ページ	案内の上で、どのページの下にぶら下がっているか	どこからもたどれないページを見つけられない
主題（狙う語）	そのページが応える問いを1つ。原則1ページに1つ	同じ語を狙うページが複数でき、互いに食い合う
最終更新日	本文に手を入れた日。公開日とは別の列で持つ	古い情報のまま残っているページを選び出せない
担当	内容に責任を持つ部署と個人	直す必要が分かっても、誰に頼めばよいか決まらない
公開状態	公開、下書き、検索結果に出さない指定、会員限定などの区別	公開しているつもりの頁が、実は外から見えていない
判定と移行先	残す・直す・まとめる・消すのどれかと、まとめる場合の統合先	棚卸しの結論が残らず、次の担当者が同じ調査をやり直す

10列のうち、後から機械では埋められないのは「主題」と「判定」の2つです。残りはCMSや解析の記録から復元できますが、この2列は人が決めた内容そのものなので、決めた記録がなければ消えます。表の設計を評価するときは、この2列が埋まる仕組みになっているかだけを見れば足ります。

管理番号については、実務の鉄則が1つあります。一度決めた番号は変更しないことです。ページを消しても番号は欠番のまま残します。番号を打ち直すと、過去の議事録や指示書に書かれた番号が別のページを指すようになり、後から履歴をたどれなくなります。行を並べ替えても番号が動かないという性質が、この列の値打ちのすべてです。

列を増やすほど、誰も埋めなくなる

10列を置くと、必ず「あの情報も入れておきたい」という話が出ます。実際、制作の現場では説明文、見出し、正規のアドレスを示す指定、検索結果に出さない指定、構造化データの有無、表示速度、計測タグの設置有無といった列も紹介されています。どれも見られれば役に立つ情報です。それでも安易に足すと、表は数か月で止まります。

判断の基準は2つに絞れます。1つ目は、その列が今回の判断を変えるかどうか。表示速度は改善の判断には効きますが、残すか消すかの判定は変えません。2つ目は、その列は自動で取れるのか、人が手で書くのかです。自動で取れる列は増えても現場の負担が変わらないので、増やしてかまいません。手で書く列は、1ページあたりの入力時間にそのまま乗ります。

目安を1つ置くなら、手で書く列は5つまでです。前の節の10列のうち、手で書くのは主に、ページ名、親ページ、主題、担当、判定の5つ。ほかは書き出しや設定から機械的に持ってこられます。手で書く列が6つ目に入りそうになったら、列を足すのではなく、その用途のための別のシートを作ります。1行を足すのに5分かかる表は、忙しい月に必ず飛ばされます。

手順1：4つの経路から全ページを集める

列が決まったら、行を集めます。ここで多くの現場が最初の壁にぶつかります。全ページの一覧が、どこか1か所にまとまって存在していないからです。冒頭で触れたとおり、公式の移転手順書も調べる場所を5か所並べています。実務ではこれを4つの経路に束ねられます。

重ねるときに必ずやることが1つあります。URLの表記を先にそろえることです。末尾の斜線の有無、通信方式の違い、大文字と小文字、末尾に付く追跡用の記号。これらが混ざったままだと、同じページが4行に分かれて、食い違いを見ているつもりが表記のゆれを見ているだけになります。そろえる規則を先に紙に書き、全経路の一覧に同じ規則を当ててから重ねます。

件数の上限にも注意が必要です。XMLサイトマップは1ファイルにつき50,000件が上限なので、大規模サイトでは分割されており、1本を見ただけでは全ページになりません。検索エンジン側のレポートも、表示される例は1,000件までで、しかも1,000件未満であっても特定の状態のURLがすべて表示されるとは限らない、と公式に注記されています。どの経路にも見えていない範囲があるという前提で重ねるのが、この手順の要点です。

4つの結果は一致しない。差分が棚卸しの本体

重ね終わると、必ず数が合いません。ここで数を合わせにいくと作業が止まります。順序が逆で、合わないところにこそ、この作業でいちばん見たかったページが集まっています。よく出る食い違いは、次の5つの型に整理できます。

• 公開一覧にあるのに、リンクをたどっても出ない……どこからも案内されていないページ。作ったまま案内を張り忘れた記事、案内から外したまま残っている旧ページがここに出る
• リンクをたどると出るのに、公開一覧にない……CMSの外で作られた頁。制作会社が個別に作った特設ページや、過去のキャンペーンの残骸が多い
• 検索エンジン側にあるのに、公開一覧にない……消したつもりで残っている頁や、追跡用の記号違いで別の住所として扱われている頁
• 解析にしか出てこない……計測用に作った住所、社内からしか踏まれない頁、外部の資料からのみ案内されている頁
• 公開一覧にあるのに、検索エンジンが採用していない……状態が「検出 – インデックス未登録」または「クロール済み – インデックス未登録」になっている頁

5つ目は、順位が低いという話とは別の問題です。公式の説明によれば、前者は検出されたがまだクロールされていない状態、後者はクロールされたがインデックスには登録されていない状態を指します。順位を上げる以前に、検索結果の候補に入っていないということです。棚卸しでは、この状態のページを直す対象に回すのか、そもそも消すのかを先に決めます。なお、サイトマップ以外の経路で見つかったURLも、サイトマップで送信されたものとして扱われる旨が明記されているため、送った覚えのないページが一覧に並ぶことがあります。

差分が出た行には、判定を書く前に「なぜここに出たのか」を書く列を1つ足します。理由が1行で書ければ判定はすぐ決まりますし、書けなければそれが次の調査の宿題になります。数が合わないこと自体は問題ではなく、合わない理由を誰も書き残していないことが問題です。この列があると、翌年に同じ作業をした人が、同じ調査を最初からやり直さずに済みます。

手順2：階層と親ページを入れ、たどれない頁を出す

行がそろったら、構造の列を埋めます。まず階層です。トップページを第1階層とし、その下のカテゴリを第2階層、個別ページを第3階層と数えます。制作の現場では3階層以内に収めるのが理想とされ、4階層以上に深くなっている箇所は要注意と扱われます。ただし深さそのものの是非は別の論点なので、この表では深い行に印を付けるところまでにとどめます。

実務で効くのは、階層より親ページの列です。住所の上での階層と、案内の上での親は一致しないことがよくあります。住所は浅いのに、実際にはどのページからも案内されていない、という頁が典型です。親ページの列を1行ずつ埋めていくと、埋められない行が残ります。親が書けない行が、どこからもたどり着けないページの候補です。前節の1つ目の食い違いと、ここで独立に炙り出されます。

親ページを埋める作業は、そのまま内部リンクの点検になります。親から子への案内が実際に張られているかを、有無だけの列で持ちます。丸が付かない行は、親を決めたのに案内が張られていない状態です。この列は手で埋めると重いので、リンクをたどる道具の出力から機械的に付けます。手で書く列を5つまでに抑える、という前節の原則を守るためです。

手順3：1ページに1つ、狙う語を決める

次に主題の列です。制作の現場では、狙う語は原則1ページに1つとされています。ここは表を作るうえで最も揉める列であり、同時に最も価値が出る列でもあります。2つ書きたくなったページは、内容が2つ入っているということなので、ページを2つに割るか、片方を捨てるかの判断が要ります。

列が埋まったら、主題の列で並べ替えます。同じ語が複数行に並んだ箇所が、社内で食い合っているページです。ページ単位で見ているうちは気づけず、全件を1枚に並べて初めて見えるので、この操作だけのために表を作る価値があります。並んだ行は、まとめる、片方の主題をずらす、片方を消す、のいずれかで解消します。どれを選んだかは判定の列に残します。

空欄の扱いも先に決めます。会社概要や問い合わせの完了画面のように、そもそも検索から入ってくることを想定しないページは、空欄ではなく「なし」と書きます。空欄と「なし」を区別しないと、埋め忘れなのか対象外なのかが半年後に分からなくなります。同じ理由で、判断がついていない行には「未定」と書きます。表の空欄は、時間がたつほど意味を失っていきます。

手順4：残す・直す・まとめる・消すを判定する

材料がそろったら判定です。区分は4つに絞ります。増やすと、どの区分にも当てはまらない行が増えて先に進まなくなります。

1. 残す……内容も主題も現状で問題がない。今回は触らない。次に見直す時期だけ決めておく
2. 直す……主題は正しいが、情報が古い、または薄い。担当と期限を同時に決める
3. まとめる……ほかのページと主題が重なっている。統合先を決め、統合後は元の住所から統合先へ転送する
4. 消す……役目が終わっている。転送先が適切に決められない場合は、消したことが分かる状態にする

判定の材料は、最終更新日、直近1年の流入の有無、主題の重複、記載内容が事実として古くなっていないか、の4点で足ります。重要なのは、判定した日と判定した人を必ず列に残すことです。半年後に「なぜこのページを消したのか」と聞かれたときに答えられるのは、この2列だけです。1人で決めず、主題の担当部署に一度戻す運用にしておくと、後の差し戻しが減ります。

実務で最も多い落とし穴は、まとめる判定の後始末です。件数としてはこの区分が最も多くなりますが、統合先の内容を書き足したところで力尽き、旧ページからの転送設定が抜けます。転送先の列を判定と同じタイミングで埋めるのが唯一の対策です。あわせて、転送の連鎖にも注意します。公式には、クローラーがたどれる連鎖は最大10個とされたうえで、直接の転送が推奨されています。2度目の移行で連鎖が伸びるので、旧い対応表を捨てずに残しておくことが効いてきます。

手順5：移行先の列を足して対応表にする

リニューアルや移行が控えている場合、ここまで作った表に移行先の列を1つ足すだけで、そのまま旧アドレスと新アドレスの対応表になります。作る順序には決まりがあり、新規制作では構成図から作るのが効率的ですが、リニューアルでは現時点の情報を先にディレクトリマップへ落とし込む、という順序が実務では定着しています。今あるものを並べてからでないと、何が減るのかが分からないためです。

移行の前に、対応表と合わせて確認しておく項目が4つあります。公式の手順書に沿って挙げると、移行先の各ページに自身を指す正規アドレスの指定があるか、新しいサイトの内部リンクを旧アドレスから新アドレスに書き換えたか、新しいアドレスを載せたサイトマップを用意したか、そして旧アドレスにリンクしている外部サイトの一覧を保存したかです。最後の1つは移行後に取り直せないので、対応表を作る段階で列に取り込んでおきます。

移行の直後には、想定しておくべき負荷があります。移転後は一時的に通常より高い頻度でクロールされるため、サーバーに十分な計算資源を確保しておくことが公式に案内されています。対応表の行数が多いほど、この期間に踏まれる転送の回数も増えます。公開日を決めるときは、行数と、当日から数日間のサーバーの余力を合わせて見ます。表の行数は、作業量の見積もりだけでなく、当日の負荷の見積もりにも使える数字です。

AIに任せてよい作業と、任せてはいけない判定

ページ数が数百を超えると、表を作る作業そのものが重くなります。AIが効くのは、この重さのうち「集める」「そろえる」「候補を出す」の部分です。任せてよい作業と、任せてはいけない判断は、はっきり分かれます。まず、任せてよいのは次の5つです。

• 4つの経路から出した一覧を1枚に重ね、URLの表記ゆれをそろえて突き合わせる
• ページ名と本文の冒頭から主題の当たりを付け、下書きとして主題の列に入れる
• 似た主題のページを束ね、まとめる候補の組み合わせを根拠つきで出す
• 社内で同じものを別の言葉で呼んでいる箇所を洗い出し、呼び方の一覧を作る
• 空欄の行、日付の前後が合わない行、階層と親ページが矛盾する行を指摘する

一方で、次の5つは人が決めます。いずれも、間違えたときに元へ戻せない種類の判断です。

• 残すか消すかの判定——消した後に必要だったと分かっても、評価もリンクも戻らない
• どのページにまとめるかの決定——統合先を誤ると、統合元と統合先の両方が沈む
• 主題の最終的な確定——自社が使う言葉と、実際に売っている順序に依存する
• 公開状態と、見せてよい範囲の扱い——契約と社内規程で決まる領域で、一般論では判定できない
• 外部に渡す一覧の中身——発注先に渡した表は、そのまま自社の説明になる

線の引き方はひとつです。AIには候補を出させ、決定は人がする。そのために、まとめる候補には必ず根拠を書かせます。どのページとどのページが、どの語で、どの見出しで重なっているのか。根拠のない候補は採用しません。判定の列だけは、人の名前と決めた日が入っていないと使えません。この2つが空欄の判定は、後から誰も責任を持てないので、表としては空欄と同じ扱いになります。

表計算ソフトで作るときの決めごと

道具は表計算ソフトで十分です。実務でも1行1URLで表計算ソフトに記載する形が標準になっています。ただし、後から使えなくなる作り方がいくつかあるので、最初に4つだけ決めておきます。1つ目は、URLを省略しない完全な形で書くこと。相対的な書き方にすると、ほかの一覧と突き合わせられません。XMLサイトマップの仕様でも完全な形が求められており、そろえておくと後の作業が減ります。

2つ目は、セルを結合しないこと。見た目は整いますが、並べ替えと絞り込みが壊れます。この表の値打ちは並べ替えにあるので、ここを潰す装飾は入れません。3つ目は、行を削除しないこと。消したページの行は残し、判定の列に「消した」と日付を書きます。削除すると、そのページが存在した事実ごと消えます。翌年、同じ主題で新しい記事を書こうとしたときに、過去に同じものがあったかどうかを確認できなくなります。

4つ目は、正となる1枚を決めることです。よくある壊れ方は、誰かが手元にコピーを取り、そちらだけが更新されて2枚が別々に育つ形です。正となる1枚の置き場所を決め、コピーを取る場合は名前に「参照用」と入れる。あわせて、表の外側に作成日と最終更新日を書いておきます。更新日の書かれていない一覧は、正しいかどうかを誰も判断できないので使われなくなります。

1回作って終わる原因と、公開手順に埋め込む形

ディレクトリマップの最大の失敗は、作れないことではなく、作った後に更新されないことです。実務でも「作って終わりにしない。定期的に更新する」ことが繰り返し注意されています。それでも止まるのは、更新が別の作業として外側に足されているからです。止まり方には型があります。

• 作成そのものを制作会社に任せ、納品後に誰が更新するかを決めていない
• ページを公開する作業と、表に1行足す作業が別の場所にあり、公開だけが先に進む
• 列が多すぎて1行を足すのに時間がかかり、忙しい月から順に飛ばされる
• 消したページの行を削除してしまい、過去に何があったのかをたどれなくなる
• 更新の当番だけ決めて、いつ見るのかを決めていないので、誰も着手しない
• 判定の列を埋めないまま並べ終えて満足し、判断に一度も使われずに放置される

続く形にする条件は3つです。公開の手順の最後に、表へ1行足す工程を入れること。そのとき埋める列を、公開の瞬間に分かるものだけに絞ること。そして、判定と移行先は後から埋めてよいと明文化することです。公開時に埋めるのは、URL、ページ名、階層、親ページ、主題、担当の6つで足ります。この6つなら、公開作業の延長で1分もかかりません。

• 公開の手順書に「表へ1行追加」を工程として書き、担当者の作業一覧に入れる
• 見直しは日付ではなく出来事で起こす。新しいカテゴリを作ったとき、特設ページを公開したとき、担当者が変わるとき、移行の見積もりを取るとき
• 月に一度見るのは全件ではなく、主題が空欄の行と、判定が「未定」のままの行の2種類だけにする
• 年に一度、4つの経路から集め直して、表に無い行が増えていないかを確かめる

よくある質問

ページ数が数千ある場合も、全件を1行ずつ並べるのですか

並べます。ただし、判定まで入れるのは絞った範囲だけで構いません。行を全件そろえておくと、後から条件を変えて何度でも絞り込めますが、最初から対象を間引いてしまうと、後から足すことができなくなります。並べる作業は経路からの書き出しが中心で機械的に進むので、件数が増えても手間は比例して増えません。手間が比例するのは、手で書く5つの列のほうです。

XMLサイトマップがあれば、ディレクトリマップは要らないのでは

役割が別です。XMLサイトマップは検索エンジンに送る機械向けの地図で、書ける内容は仕様で決まっています。更新頻度と優先度の指定は無視されると公式に明記されており、担当者や判定を書く場所はそもそもありません。加えて、1ファイルにつき50,000件という上限があるため、大規模サイトでは分割されていて全体像を1枚で見ることもできません。判断のための表としては使えない、という理解が実務に合います。

誰が作るのが正しいですか。制作会社に頼むべきですか

集める作業は外部に頼めますが、主題と判定の2列は社内で埋めます。この2列は事業の言葉づかいと今後の売り方に依存するので、外から埋めても後で全部書き直しになります。発注する場合は、経路からの書き出しと突き合わせまでを依頼し、主題と判定の列は空欄で納品してもらう形が実務的です。納品後に誰が更新するかも、発注の時点で決めておきます。

どのくらいの頻度で更新すればよいですか

頻度ではなく、出来事で起こすほうが続きます。ページを公開したその場で1行足す運用にしておけば、定期的な更新はほとんど不要になります。そのうえで、年に一度だけ4つの経路から集め直し、表に無い行が増えていないかを確かめます。増えていれば、公開の手順から抜け落ちている経路があるということなので、直すのは表ではなく手順のほうです。

競合サイトのディレクトリマップも作れますか

作れます。外から見える経路、つまりリンクをたどる方法と、公開されているサイトマップの2つが使えます。自社と競合2社から3社分を横に並べると、競合にあって自社に無いページの区分や、片方だけ内容が厚い領域が浮かびます。ただし出せるのは外から見える範囲だけで、公開されていないページや会員向けの領域は入りません。抜けがある前提の比較であることを、資料の側に明記しておきます。

まとめ

ディレクトリマップは、サイトにある全ページを1行ずつ並べた社内用の表です。検索エンジンに送るXMLサイトマップとも、来訪者向けに公開する一覧ページとも別物で、消したいページも隠しているページも載っている唯一の表という点に値打ちがあります。呼び方はサイト構成表でも全ページ一覧でも構いません。図ではなく表の形をしているのは、並べ替えと絞り込みで判断に使うためです。

書く列は10。管理番号、URL、ページ名、階層、親ページ、主題、最終更新日、担当、公開状態、判定と移行先です。このうち後から機械では埋められないのは主題と判定の2列で、表の設計はこの2列が埋まるかどうかで決まります。列は増やすほど埋まらなくなるので、手で書く列は5つまでを目安にし、移行前・棚卸し・発注という場面ごとに立てる列を変えます。

行を集める経路は4つあります。CMSからの書き出し、サイト内のリンクをたどる方法、検索エンジン側の記録、そしてアクセス解析に出てくる住所です。この4つの結果は必ず食い違い、食い違ったところに、どこからもたどれないページや、消したつもりで残っているページが集まります。数をそろえてから作るのではなく、合わない理由を列に書き残すのが棚卸しの本体です。AIには重ねる作業と候補出しを任せ、残す・消す・どこにまとめるかの判定は人が決め、決めた日と決めた人を必ず残します。

始め方も難しく考える必要はありません。まずはCMSからの書き出し1本で構わないので、URLとページ名を並べた表を1枚作ってください。そのうえで、主題の列を埋めながら並べ替えると、食い合っているページがその日のうちに見つかります。完成させてから使うのではなく、埋まっていない列がある状態のまま使い始めるほうが、この表は続きます。全体像が1枚にある会社と、無い会社では、リニューアルの見積もりを取る時点で差が出ます。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。