ホームページ納品後に自分でどこまで更新できるか｜納品時に受け取る7点と、触ってよい範囲の線引き

ホームページが完成して納品されたあと、いちばん最初につまずくのが「どこまで自分で直していいのか分からない」という状態です。文章くらいは変えられそうだけれど、触った瞬間にデザインが崩れたら怖い。かといって句読点ひとつ直すのに制作会社へ連絡していたら、更新が止まります。

結論から書きます。納品後に自社で更新できる範囲は、担当者のパソコンの得意・不得意ではなく、サイトの作られ方で決まります。 そして、その範囲は納品の瞬間に自動で決まるものではなく、発注の段階で決めておける項目です。

判断の軸は次の3つです。

1. 納品時に「何を受け取るか」（受け取り損ねると後から取り戻すのに費用がかかるものがある）
2. 更新の対象を4つの階層に分け、どこまでを自社の担当にするかを書面で線引きする
3. 更新したあと、直ったことをどう確かめるかの手順を決めておく

この3つが決まっていれば、納品後に「これは触っていいのか」と迷う場面はほぼなくなります。順番に見ていきます。

1. 納品時に受け取るもの7点

制作物のデータだけを受け取って完了にすると、あとから困ります。実務で「これが揃っていれば移行も更新も詰まらない」と言えるのは、次の7点です。

#	受け取るもの	受け取り損ねたときに起きること
1	ドメインの契約先と、名義が誰か	制作会社名義のサブドメインだと、将来の独自ドメイン移行が自社判断でできない
2	サーバーの契約先とアカウント	会社を変えるとき、データの取り出しから交渉になる
3	管理画面のURLと自社用アカウント	制作会社のアカウントを共用していると、退任・解約時に一斉に止まる
4	更新マニュアル（そのサイト専用のもの）	一般的なWordPress入門書では、実際の画面と文言が合わない
5	アクセス解析・検索管理ツールの所有権	所有者が制作会社のままだと、データを引き継げない
6	元画像・ロゴの元データ	圧縮済みの画像しかないと、看板やチラシに転用できない
7	保守の範囲を書いた書面	「これは保守に含まれますか」の確認が毎回発生する

とくに注意したいのが1と5です。

ドメインは、名義が誰かで将来の選択肢が変わります。 制作会社が持つ共有ドメインのサブドメイン（例：あなたの店名.制作会社のドメイン）で公開する形は、初期費用を抑えられる代わりに、そのURLはあなたの資産にはなりません。実際の納品案内では、この点を「共有ドメインでの公開である」「将来の独自ドメイン移行は可能だが要相談」と明記しておくのが誠実な書き方です。安く始めること自体は悪くありません。書いていないことが問題になります。

アクセス解析と検索管理ツール（Googleアナリティクス／サーチコンソール）は、所有権を自社のGoogleアカウントで取得しておくのが原則です。 制作会社は「権限を付与される側」に置きます。順序を逆にすると、契約が終わったときに過去のデータごと持っていかれる形になります。制作側の作業としては、確認用ファイルの設置まで済ませておき、クライアントは自分のアカウントで確認ボタンを押すだけ、という形にすれば所有権は最初から自社に残ります。

2. 触ってよい範囲を4階層で線引きする

「自社で更新できます」という言葉は、実は4つの階層に分かれています。ここを分けずに契約すると、認識がずれます。

第1層：本文と画像の差し替え（自社でやる）

固定ページの文章、写真の入れ替え、お知らせやブログの投稿。ここは自社で回すのが前提です。反映が早いことに価値がある領域なので、いちいち依頼していると鮮度が落ちます。

第2層：設定値の変更（自社でやる／作りに依存）

料金、実績件数、営業時間、対応エリアといった数字や項目そのものの変更です。ここが重要で、本文にベタ書きされているか、管理画面の設定項目になっているかで難易度がまったく変わります。

料金を本文中に直接書いてしまうと、改定のたびに全ページを探して直すことになり、必ずどこかに古い金額が残ります。制作を依頼する段階で「料金は本文ではなく設定項目で管理してほしい」と伝えておくと、後の数年が変わります。

第3層：投稿型コンテンツの追加（自社でやる／設計が必要）

施工事例、お客様の声、よくある質問（FAQ）など、件数が増えていくものです。これは第1層とは別に考える必要があります。

なぜかというと、検索エンジンやAIに読ませるための構造化データ（JSON-LD）が、追加した分にも自動で付くかどうかが分かれるからです。公開時に制作会社が手作業で構造化データを書き込む作りだと、そのあと自社でFAQを1本足しても、そこにはタグが付きません。更新すればするほど、構造化されていないページの割合が増えていくという状態になります。

正しい作りは逆です。事例やFAQを、ブログ記事と同じように項目立てされたフォームから追加する専用の投稿枠として設計しておき、保存した時点でその内容が自動で構造化データに変換される形にします。入力欄はあらかじめ決めておきます。

• 施工事例なら：エリア／建物種別／作業内容／費用／作業時間／写真
• FAQなら：質問／回答

こうしておけば、事例を1本足せば構造化された事例が1本増えます。HTMLもタグも一切触りません。この設計は素のWordPressに標準で付いてくるものではないので、「自社で育てたい」という方針があるなら、発注時に明示的に依頼する項目だと考えてください。

第4層：レイアウト・機能・デザイン（制作会社に依頼する）

ページの型そのものの改変、新しい種類のページの追加、構造化データの項目を増やす作業、デザインの全面変更。ここは自社で触らない領域として線を引きます。

実務では、納品資料に「外観／プラグイン／設定のメニューは、触る前にご相談ください」と一文入れておくのが有効です。禁止ではなく相談、という書き方にしておくと、必要な変更が止まらずに済みます。

3. 「ページ数」の数え方は先に決める

納品後のトラブルで多いのが、追加費用の解釈違いです。「6ページまで」という契約で、事例を50件足したら追加請求が来るのか。

ここは、契約前にこう定義しておけば揉めません。

• 固定ページ（トップ・サービス詳細・会社概要・対応エリア・お問い合わせなど）はページ数の枠に数える
• 投稿として増えていくもの（施工事例・FAQ・ブログ）は、何件増えても枠に数えない
• ただし、事例やFAQの一覧ページは固定ページ扱い

3つ目を書き忘れると、認識がずれます。曖昧なまま進めて納品後に請求の話をするより、見積もりの段階で自分から数え方を開示したほうが、結果的に信頼されます。

4. 更新マニュアルは「そのサイト専用」でないと機能しない

汎用のWordPress入門資料を渡しても、実際にはほとんど使われません。画面に出ている文言と、資料に書いてある言葉が一致しないからです。

実際に納品しているマニュアルは、A4で4〜5ページに収め、次の構成にしています。

1. サイトのURLと管理画面のURL
2. ログイン方法（IDとパスワードは資料に書かない）
3. 固定ページの文字を変える手順
4. 画像を差し替える手順
5. 設定画面で料金・実績を変える手順
6. 事例・FAQを追加する手順
7. 崩れていないことを確認する手順

2番目が実務上のポイントです。ログイン情報をマニュアル本体に印刷すると、その資料が社内で回覧・転送された時点で管理できなくなります。 管理画面のURLだけを載せ、IDとパスワードは別経路で渡すのが安全です。あわせて、パスワードの変更手順（管理画面のユーザー→プロフィール）も載せておきます。

そしてもうひとつ。画面のスクリーンショットは、そのサイトで実際に使われている文言のまま載せます。 ボタンが「画像を選ぶ」「この画像を使う」「初期画像へ戻す」「更新」「設定を保存」と表示されているなら、マニュアルの説明文もその言葉で書きます。一般名詞に置き換えた説明は、読み手が画面上でその言葉を探せず、そこで手が止まります。

5. 更新したあとの確認手順を決めておく

自社更新の運用でいちばん見落とされるのが、ここです。

管理画面で「更新」を押して画面が切り替わったことは、反映された証拠にはなりません。 保存処理が途中で失敗しても、画面だけは次に進むことがあります。確認手順としては、次の2つを決めておけば十分です。

1. 保存したあと、その編集画面をもう一度読み込み直して、入力した内容が残っているかを見る
2. シークレットウィンドウで本番のURLを開いて、実際のページで変わっているかを見る

2番目を分けているのは、キャッシュ（表示を速くするために一時保存された古い画面）や、更新後にサイトを組み直す仕組みが入っている場合、保存は成功していても表示への反映に時間差があるためです。とくに、更新した内容をサイト全体に反映するためにビルド処理が走る構成では、数十秒から数十分の遅れが出ることがあります。この時間差を知らないと「保存できていない」と誤解して同じ作業を何度も繰り返すことになるので、遅れがある構成なら、その待ち時間を納品時に必ず伝えておきます。

6. 複数人で更新するなら、変更の記録を残す

社内の複数人、あるいは自社と制作会社の両方がサイトを触る体制なら、もうひとつ決めておくべきことがあります。誰がいつ何を変えたかを、サイトの外に記録することです。

同時に編集しなくても事故は起きます。よくあるのが、午前に担当者Aが意図を持って追加した要素を、夜に担当者Bが「不要に見えた」という理由で削除してしまうパターンです。時間が空いているので競合エラーも出ませんし、誰も間違ったことをしていません。前の変更の理由が共有されていないだけで、判断が逆に振れます。

対策はシンプルで、次の3つで足ります。

• 変更したら、日付・変更箇所・変更した理由を1行だけ共有の場所（チャットでも表計算でも可）に残す
• 本番を触る前に、同じページの直近の記録を見る
• 前の変更を取り消す判断をするときは、なぜ取り消したかも残す

「理由」を残すのが要点です。何を変えたかだけの記録では、次の人が同じ迷いをして、同じ判断のブレを繰り返します。

発注前に確認しておく質問リスト

ここまでの内容を、発注前の確認事項としてまとめます。制作会社に投げる質問としてそのまま使えます。

1. ドメインの名義は自社になりますか。共有ドメインの場合、独自ドメインへの移行はできますか
2. アクセス解析と検索管理ツールの所有権は、自社のアカウントで取得してもらえますか
3. 料金・営業時間・実績件数は、本文ではなく設定項目から変更できますか
4. 施工事例やFAQを自社で追加したとき、構造化データは自動で付きますか
5. ページ数の数え方はどうなりますか。投稿として増えるものは枠に数えますか
6. 更新マニュアルは、このサイト専用の画面と文言で作られますか
7. 更新してから実際のページに反映されるまで、時間差はありますか
8. 保守に含まれる作業と、別途見積になる作業の境界はどこですか

まとめ

納品後に自分でどこまで更新できるかは、納品されてから調べることではありません。発注の段階で決められる仕様です。

• 更新の範囲は4階層に分ける。第1層（本文・画像）と第2層（設定値）は自社、第3層（事例・FAQ）は設計次第で自社、第4層（レイアウト・機能）は依頼
• ドメインの名義と解析ツールの所有権は、最初に自社側へ寄せておく
• マニュアルは、そのサイトの実際の文言で作る。ログイン情報は本体に書かない
• 更新後は、編集画面の再読み込みと、シークレットウィンドウでの本番確認をセットにする
• 複数人で触るなら、変更内容ではなく変更した理由を残す

自社で更新できる状態で納品するのが本来の前提で、保守契約は「そのうえで時間が取れない」「相談先が欲しい」場合の選択肢です。必須ではありません。まず範囲を線引きし、そのうえで外に出す部分だけを保守に預ける。 この順番で決めると、更新が止まらないサイトになります。