
ホームページを作成したものの、「アップロードの手順があいまいで不安」「制作会社からデータを受け取ったが、どこにどう置けばよいかわからない」という担当者は少なくありません。本記事では、Webサイト制作後にホームページを公開するまでの流れを整理し、失敗しやすいポイントを避けながらアップロードを完了させるための7つの手順を、サーバー・ドメイン・FTP・SSLまで一通り解説します。自社サイトを安全かつ効率的に公開・運用するための基礎を身につけたい方に役立つ内容です。
目次
ホームページ公開の全体像を理解する

ホームページの公開作業は、単にファイルをサーバーにアップロードするだけではありません。「どんな仕組みで、どこまでできれば公開完了と言えるのか」を理解しておくと、制作会社とのコミュニケーションや社内調整がスムーズになります。
ホームページ公開の全体像は、おおまかに次の流れで整理できます。
| 段階 | 内容 | 担当になりやすい人 |
|---|---|---|
| 1. 制作 | デザイン・コーディング・テキスト作成 | 制作会社 / 社内担当 |
| 2. インフラ準備 | ドメイン取得・サーバー契約・SSL準備 | 情シス / 担当者 |
| 3. アップロード | HTMLや画像などのファイルをサーバーに送信 | 制作会社 / 担当者 |
| 4. 表示確認 | PC・スマホでの表示確認、不具合の修正 | 担当者 / 制作会社 |
| 5. 計測設定 | アナリティクス、サーチコンソールなどの設定 | マーケ担当 |
「アップロード」はあくまで全体の一工程であり、ドメイン設定やSSL、表示確認・計測設定まで含めて初めて“公開完了”となります。まずは、この全体像を押さえたうえで、次の見出しから各工程を分解して理解していくことが重要です。
Webサイト制作と公開作業の関係を整理する
ホームページ制作は、大きく分けて「設計・制作フェーズ」と「公開・運用フェーズ」に分かれます。デザインやコーディングは前半の作業であり、ブラウザからアクセスできる状態にするには、完成したファイルをサーバーに配置し、ドメインとSSLを含めた公開設定を行う作業が別途必要です。
制作会社に依頼している場合でも、契約内容によっては「公開作業」「サーバー・ドメインの管理」が含まれないケースがあります。その場合、事業者側や社内担当者が、レンタルサーバー契約・ドメイン設定・アップロード作業を行う必要があります。
まとめると、Webサイト制作=ページを作ること、公開作業=インターネット上で閲覧可能にする最後の工程です。両者の役割を整理しておくと、制作会社との役割分担や、自社でどこまで対応するかの判断がしやすくなります。
アップロードとは何をどこに送る作業か
ホームページのアップロードとは、制作したWebサイトのファイルを「自分のPC」から「インターネット上のサーバー」に転送する作業を指します。転送されたファイルを、ブラウザが読み取れる場所(公開ディレクトリ)に置くことで、初めてURLからアクセスできる状態になります。
一般的に送信する主なデータは以下のようなファイルです。
- HTMLファイル(.html, .htm)
- CSSファイル(.css)
- JavaScriptファイル(.js)
- 画像ファイル(.jpg, .png, .gif, .svgなど)
- フォントやPDFなどの各種リソース
多くのレンタルサーバーには、public_html や htdocs などといった公開用フォルダが用意されています。アップロードの目的は、「公開用フォルダ」にファイル一式を正しい構成で置くことです。誤った場所に転送すると、URLを開いても「404エラー」や真っ白な画面になるため、どのフォルダに送るかを理解しておくことが重要です。
公開前に準備しておくべき4つの要素

ホームページを公開する前には、少なくとも「公開用データ」「サーバー」「ドメイン」「SSL証明書」という4つの要素を準備しておく必要があります。この4つが適切にそろっていない状態でアップロードしても、ページが表示されなかったり、URLが不自然になったり、セキュリティ警告が出たりします。
まず、HTML・CSS・画像・JavaScriptなどの「公開用データ」を整理し、どのフォルダ構成でアップロードするかを決めます。次に、レンタルサーバーを契約し、FTP情報や管理画面URLを控えておきます。あわせて、どのドメイン(例:example.co.jp)で公開するかを決めて取得し、サーバーと紐づけできる状態にします。最後に、常時SSL化を前提にSSL証明書の有無と設定方法を確認しておきます。
これら4つの要素を事前に整理しておくことで、公開作業中の手戻りやトラブルを大きく減らせます。次のセクションでは、この4つのうち「公開用データ」に含まれる具体的なファイルの種類と整理の仕方を解説します。
HTMLや画像など公開用データの種類を整理する
ホームページ公開前に整理しておくべき「アップロード対象のデータ」は、主に次のような種類があります。
| 種類 | 具体例 | 役割 |
|---|---|---|
| HTMLファイル | index.html、service.html など | ページの本文や構造をブラウザに伝える中核データ |
| CSSファイル | style.css、reset.css など | 文字サイズや色、レイアウトなどデザインを定義するファイル |
| 画像ファイル | .jpg、.png、.gif、.webp など | 写真やバナー、ロゴなどのビジュアル素材 |
| JavaScriptファイル | main.js、analytics.js など | メニューの開閉やスライダー、フォームチェックなど動きを制御 |
| フォント・動画・PDFなど | .woff、.mp4、.pdf など | Webフォント、埋め込み動画、資料ダウンロード用データ |
重要なポイントは「ローカル環境で表示に使っているファイルは、例外なくサーバーにもアップロードする」ことです。
HTMLだけでなく、CSS・画像・JavaScriptなど関連する全てのファイルを、ローカルと同じフォルダ構成でまとめて準備しておくと、アップロード後の表示崩れやリンク切れを大幅に減らせます。
レンタルサーバーの種類と選び方のポイント
レンタルサーバーは大きく分けて「共有サーバー」「VPS」「クラウド」「専用サーバー」があり、多くの中小企業サイトやコーポレートサイトは価格と運用負荷のバランスが良い共有サーバーで十分です。アクセス数が非常に多い場合や、独自のシステムを動かす場合のみ、VPSやクラウドを検討するとよいでしょう。
代表的な種類と特徴をまとめると、次のようになります。
| 種類 | 特徴 | こんなケースに向く |
|---|---|---|
| 共有サーバー | 他社と1台を共有、月額数百〜数千円、設定が簡単 | 一般的な企業サイト、採用サイト、ブログ、LP |
| VPS | 仮想サーバーを専有、自由度が高いがサーバー知識が必要 | Webアプリ、独自CMS、技術者が社内にいる場合 |
| クラウド | 利用量に応じた従量課金、柔軟にスケール可能 | アクセス変動が大きいサービス、大規模サイト |
| 専用サーバー | 物理サーバーを1社で占有、費用は高いが高性能 | 大規模ポータル、金融系など高負荷・高セキュリティ用途 |
選定時は、想定アクセス数・運用体制(社内に技術者がいるか)・予算・サポート体制・自動バックアップやSSL標準対応の有無をチェックすることが重要です。WordPressを使う予定がある場合は、「簡単インストール」機能と「PHP・データベース対応」が整ったレンタルサーバーを選ぶと、公開後のアップロード作業もスムーズになります。
ドメインとURLの基本と設定の考え方
ドメインとURLは、インターネット上の「住所」と「部屋番号」のような関係です。ドメインは「example.co.jp」のようにサイト全体の場所を示す名称、URLは「https://example.co.jp/service/」のようにページ単位の場所を示す文字列です。レンタルサーバーと契約しただけでは、まだ住所がない状態のため、独自ドメインを取得し、サーバーと紐づける設定が必要になります。
代表的なURL構造は次の通りです。
| 要素 | 例 | 役割 |
|---|---|---|
| スキーム | https:// |
通信方法(SSL有無も含む) |
| ホスト名 | www.example.co.jp |
アクセス先のサーバー名 |
| パス | /company/ |
フォルダ・ページの場所 |
| クエリパラメータ | ?id=123 |
絞り込みなどの条件 |
設定の考え方として重要なのは、「基本となるURLを最初に決めてブレさせない」ことです。特に次の3点を決めておきます。
wwwあり/なしをどちらを正とするか- 末尾スラッシュ(
/companyと/company/)の扱いを統一するか - 日本語URLを使うか、英単語・ローマ字に統一するか
これらをあいまいにしたまま公開すると、後からリダイレクト設定やリンク修正が大量に発生し、SEOにも悪影響が出ます。レンタルサーバーの管理画面やCMSの一般設定で、基本URL(サイトURL)を公開前に必ず決定・設定しておくことが、トラブル防止につながります。
SSL証明書と常時SSL化の基礎知識
SSL証明書は、アクセス中のユーザーとWebサーバー間の通信を暗号化し、「このサイトは本当にこのドメインの運営者が管理している」ことを第三者機関が保証する仕組みです。アドレスバーがhttps://で始まり、鍵マークが表示されていれば、SSL(正確にはTLS)で保護された状態になります。
現在は、全ページをhttps化する「常時SSL化」が実質必須の前提です。理由は主に3つあります。
| 観点 | 常時SSL化が必要な理由 |
|---|---|
| セキュリティ | 問い合わせフォームやログイン情報、Cookieなどを盗聴・改ざんから守るため |
| SEO | Googleがランキングシグナルとしてhttpsを明示しているため |
| ユーザー信頼 | Chromeなど主要ブラウザでhttpページに「保護されていない通信」警告が出るため |
レンタルサーバーの多くは無料SSL(Let’s Encryptなど)を提供しています。ホームページ公開時には、サーバー管理画面でSSLを有効化 → httpからhttpsへのリダイレクト設定 → サイト内リンクや計測タグのURLもhttpsに統一という流れをセットで行うことが重要です。
ホームページを送る方法別の特徴を比較する

ホームページを公開する方法は複数あり、どの方法を選ぶかで作業量や柔軟性、トラブル時の対応しやすさが大きく変わります。代表的な方法を整理すると、次の4つに分けられます。
| 方法 | 主な対象 | 特徴・メリット | デメリット・注意点 |
|---|---|---|---|
| FTPソフトでアップロード | HTMLで作成した静的サイト等 | 汎用性が高く、細かいファイル管理ができる | 設定がやや難しい、誤操作による削除・上書きリスクがある |
| サーバー管理画面のファイルマネージャ | 小規模サイト、スポット更新 | ブラウザだけで完結し、インストールが不要 | 大量ファイルの転送や同期には不向き |
| CMS(WordPressなど)の管理画面 | ブログ型・更新頻度が高いサイト | ブラウザからコンテンツを更新でき、非エンジニア向き | テーマやプラグインの構成を誤ると、表示崩れや白画面になりやすい |
| GitHub Pagesなど静的ホスティング | エンジニア寄り、開発者向け | コストが低く、高速で安定した配信が可能 | GitやMarkdownなどの知識が前提になる |
中小企業サイトやコーポレートサイトでは、「HTMLベースならFTP+ファイルマネージャ」「更新量が多いならWordPress」という組み合わせが現実的な選択肢になります。次の見出し以降で、それぞれの方法の使い方と注意点をより具体的に解説していきます。
FTPソフトを使う方法のメリットと注意点
FTPソフトは、ホームページをサーバーへアップロードする最も一般的な方法です。ファイル数が多い更新や定期的な修正があるサイトでは、FTPソフトを使えるかどうかが運用効率を大きく左右します。
まずメリットとして、(1) まとめて大量のファイルを高速に転送できる、(2) ローカルとサーバーのフォルダ構成を見比べながら作業できる、(3) 更新日時や権限など細かな情報を確認しながら運用できる点が挙げられます。特に、制作会社から引き継いだサイトや静的HTMLサイトでは、FTPソフトがあると管理が非常に楽になります。
一方で注意点もあります。誤ったフォルダにアップロードすると、既存サイトが上書き・削除されてしまうリスクがあるため、公開対象のディレクトリ(例:/public_html や /www)を事前に確認することが重要です。また、FTPは暗号化されないため、可能であればFTPSやSFTPなど暗号化された接続方式を利用し、ID・パスワードを安全に管理する必要があります。権限の強いアカウント情報は、社内で誰でも使える状態にしないこともポイントです。
サーバー管理画面のファイルマネージャを使う場合
ファイルマネージャを使う場面とメリット
サーバー会社の管理画面から利用できる「ファイルマネージャ」は、ブラウザだけでホームページを公開できる機能です。専用ソフトのインストールが不要なため、
少量の修正や、社外PCからの緊急対応には最も手軽な方法と言えます。また、権限が制限されたアカウントでログインすれば、担当者ごとに操作範囲を絞りやすい点も利点です。
一方で、大量ファイルの転送や階層構造の管理はやや操作しづらく、転送速度もFTPに劣ることがあります。初回の大量アップロードはFTP、公開後の細かな修正はファイルマネージャといった役割分担を行うと効率的です。
基本的な操作の流れ
一般的なレンタルサーバーでは、次のような手順で利用します。
- サーバーの管理画面(コントロールパネル)にログインする
- 「ファイルマネージャ」「ファイル管理」などのメニューを開く
- ドキュメントルート(
public_htmlやwwwなど)に移動する - 「アップロード」ボタンから、PC上のHTMLや画像ファイルを選択する
- 必要に応じてフォルダを作成し、階層構造を整える
アップロード先が公開用フォルダかどうかを毎回確認することが重要です。誤って1階層上に置くと、インターネットからは参照されないため注意が必要です。
注意しておきたいポイント
ファイルマネージャはブラウザ操作であるため、ドラッグ&ドロップや複数選択の挙動が環境によって異なる場合があります。特に注意したい点は次の通りです。
- 上書きアップロード時の確認メッセージを必ず読む
- 不要なファイルやフォルダを削除する前にバックアップを取得する
- 圧縮ファイル(ZIP)をアップロードしてサーバー側で解凍できるかどうかを確認する
本番環境での直接編集は、誤操作・タイポがそのまま公開されるリスクがあるため最小限に抑えることが推奨されます。コードの大きな変更は、ローカル環境でテストしてから反映すると安全です。
WordPressなどCMS利用時の公開の考え方
CMS(WordPressや各種クラウド型サービス)では、「サーバーへファイルをアップロードする」というより「管理画面からコンテンツを更新する」ことが公開作業になります。テーマ・プラグイン・画像などの技術的なファイルはCMS側が処理するため、従来型のHTMLサイトよりも「どこに何を置くか」を意識する場面は少なくなります。
一方で、公開の考え方としては次のポイントを押さえる必要があります。
- テーマやプラグインの更新=サイト構造や表示に影響する「大きな変更」になるため、事前バックアップとテスト環境の利用が重要
- 固定ページや投稿の公開ステータス(下書き/公開/予約投稿)を正しく管理し、意図しないタイミングで公開しないようにする
- 画像やPDFなどのメディアは「メディアライブラリ」からアップロードし、ファイル名・容量・代替テキストを意識して管理する
- キャッシュプラグインやCDNを使っている場合、変更がすぐに反映されないことがあるため、「キャッシュの削除」も公開作業の一部と考える
CMS利用時は「FTPでアップロードする作業」を極力減らし、管理画面中心で運用することが安全かつ再現性の高い公開方法といえます。制作会社に構築を依頼している場合は、どこまで管理画面で更新できるか、どの操作は行わない方が良いかを事前に確認しておくと運用トラブルを防ぎやすくなります。
GitHub Pagesなど静的ホスティングの選択肢
静的ホスティングとは何か
GitHub Pagesなどの静的ホスティングは、HTML・CSS・JavaScriptなど「生成済みのファイル」だけをそのまま配信するサービスです。PHPやデータベースは使えませんが、その分サーバー構成がシンプルで、セキュリティリスクも比較的低くなります。問い合わせフォームや検索などの動的機能は、外部サービス(フォームサービス、ヘッドレスCMSなど)と組み合わせて実現するケースが一般的です。
主なサービスと特徴
| サービス名 | 特徴・メリット | 向いているケース |
|---|---|---|
| GitHub Pages | 無料、Git管理と連携、HTTPS標準、技術情報が豊富 | 技術系企業のサイト、シンプルなコーポレートサイト |
| Netlify | 自動デプロイ、フォーム機能、リダイレクト設定が容易 | LPやキャンペーンサイト、Jamstack構成 |
| Vercel | Next.jsなどモダンJSと相性抜群、CDN標準 | 技術寄りサービスのマーケサイト |
小規模〜中規模で更新頻度がそれほど多くないサイトであれば、コーポレートサイトでも十分候補になります。
静的ホスティングを選ぶメリット・デメリット
メリット
- サーバー管理がほぼ不要で、運用コストが低い
- パフォーマンスが高く、表示速度が速い
- 仕組みがシンプルなため、障害やセキュリティ事故のリスクが抑えられる
デメリット
- CMSのような「管理画面から更新」が基本的にない
- お問い合わせフォームや会員機能などは外部サービス頼みになる
- 社内でHTML編集スキルを持つ担当者が必要になりやすい
ビジネスサイトで利用する際の判断ポイント
次の観点で、WordPressなどのCMSと比較検討すると判断しやすくなります。
- 今後、社内担当者が管理画面から頻繁に更新したいか
- ブログやニュースを大量に追加していく運用があるか
- 問い合わせ、資料請求、予約などの機能をどの程度組み込みたいか
「更新頻度は低い・機能もシンプル・運用コストを抑えたい」場合は、静的ホスティングが有力な選択肢になります。一方で、更新主体が非エンジニアの担当者である場合や、コンテンツ量・機能が増える予定がある場合は、前項で説明したCMSの利用もあわせて検討するとよいでしょう。
ホームページ公開の手順7つの全体フロー

ホームページ公開の作業は、思いついた順に行うとトラブルの原因になります。「何を・どの順番で行うか」をあらかじめ整理してから着手することが、公開で失敗しない最大のポイントです。
この記事では、一般的なレンタルサーバー+独自ドメインを想定し、ホームページ公開までの流れを次の7ステップで整理します。
- 契約情報とログイン情報を整理する
- ドメインとサーバーの紐づけを行う
- FTPクライアントソフトを準備する
- 接続設定と接続テストを実施する
- ディレクトリ構成とトップページを確認する
- ファイルをアップロードし表示を確認する
- SSL設定とwww有無の統一を行う
上から順に実行することで、URLが間違っていた、表示されない、httpとhttpsが混在しているといった典型的な失敗を避けやすくなります。続く項目で、各ステップのポイントを詳しく解説します。
手順1 契約情報とログイン情報を整理する
ホームページ公開の作業に入る前に、レンタルサーバーやドメインの「契約情報」と「ログイン情報」を整理しておくことが、公開トラブルを防ぐ最初のステップです。担当者交代や外部パートナーとのやりとりが多い企業ほど、ここが曖昧なまま進んで混乱しがちです。
整理しておきたい主な情報は次の通りです。
| 分類 | 必要な情報の例 |
|---|---|
| レンタルサーバー | 申込者名義、プラン名、契約ID、管理画面URL、ログインID/パスワード、サーバー名、FTPアカウント情報 |
| ドメイン | 契約事業者、ドメイン名、契約ID、更新期限、ネームサーバー情報、管理画面URL、ログイン情報 |
| 付帯サービス | SSL証明書の発行元、契約状況、メールアドレスの設定情報など |
特にビジネス利用の場合は、個人のPCやメールソフトにだけ保存せず、社内で共有できる台帳(スプレッドシートなど)にまとめ、アクセス権を制御しながら管理することが重要です。この整理ができていると、次の手順で行うドメインとサーバーの紐づけやFTP設定もスムーズに進みます。
手順2 ドメインとサーバーの紐づけを行う
ドメインとサーバーの紐づけを行わない限り、ブラウザのアドレスバーに入力されたURLからホームページへ到達できません。ドメイン管理会社側の設定(DNS設定)と、レンタルサーバー側の設定(ドメイン追加)を両方行うことが重要です。
一般的な流れは次の通りです。
- ドメインを取得した管理画面にログインする
- DNS設定画面で、サーバー会社から案内されているネームサーバー情報、またはIPアドレスを登録する
- レンタルサーバーの管理画面で、対象ドメインを「追加」または「割り当て」する
- ドキュメントルート(公開フォルダ)を確認し、後続のアップロード手順で利用する
DNSの変更は、反映まで数時間〜最大72時間程度かかる場合があります。公開スケジュールに余裕を持ち、切り替え当日は「旧サイトが表示されるか」「新サイトが表示されるか」が地域によって混在する可能性があることも想定しておくと安心です。
手順3 FTPクライアントソフトを準備する
FTPクライアントソフトは、ローカルPCのファイルをサーバーへ転送するための専用ツールです。ブラウザだけでは細かなアップロード操作が難しいため、ホームページ公開作業を安定して行うにはFTPソフトの準備がほぼ必須と考えて問題ありません。
代表的なFTPクライアントとしては、以下のようなものがあります。
| 種類 | OS | 特徴 |
|---|---|---|
| FFFTP | Windows | 無料で基本機能が揃う。情報も多く、初心者向け |
| FileZilla | Windows / Mac | クロスプラットフォームで使える。SFTP対応 |
| Cyberduck | Windows / Mac | シンプルな操作性。クラウドストレージ連携も可能 |
重要なのは「サーバー側が推奨しているソフトを優先して選ぶこと」です。レンタルサーバー各社のマニュアルに、推奨FTPソフトや設定例が掲載されているため、自社のサーバー名で検索し、対応しているツールを確認しておくとスムーズです。また、FTPではなくSFTP(暗号化された接続)に対応したソフトを選ぶと、セキュリティ面でも安心です。
手順4 接続設定と接続テストを実施する
接続に必要な情報を整理する
FTPソフトからサーバーへ接続するためには、レンタルサーバーの管理画面で次の情報を確認します。1つでも誤りがあると接続できないため、事前確認が重要です。
- ホスト名(例:ftp.example.com、サーバー名、IPアドレスなど)
- ユーザー名(FTPアカウント名)
- パスワード
- 接続方式(FTP/FTPS/SFTP など)
- ポート番号(通常は21、SFTPは22など)
サービスによって名称が「FTPアカウント」「サーバー情報」「接続情報」などと異なるため、マニュアルも確認すると確実です。
FTPソフトに設定を入力する
確認した情報をFTPソフトの「新規ホスト」「新規接続」などの画面に登録します。一般的には以下のように入力します。
| FTPソフト側の項目例 | 入力内容の例 |
|---|---|
| ホスト名 | サーバー指定のホスト名 or IPアドレス |
| ユーザー名 | FTPユーザー名 |
| パスワード | FTPパスワード |
| ポート | 指定がなければ空欄 or 21 |
| 転送プロトコル | FTP / FTPS / SFTP から指定 |
セキュリティ面から可能であればFTPSまたはSFTPを選択し、暗号化された接続を利用します。入力後は設定を保存しておくと、次回以降の接続がスムーズです。
接続テストとエラー時の確認ポイント
設定が完了したら「接続」ボタンでテスト接続を行います。正常に接続できれば、右側にサーバー内のフォルダ一覧が表示されます。
接続できない場合は、以下の順で原因を切り分けます。
- ホスト名・ユーザー名・パスワードのタイプミス
- 接続方式(FTP/FTPS/SFTP)の選択ミス
- ファイアウォールやセキュリティソフトによるブロック
- 同時接続数制限など、サーバー側エラー
設定値を1つずつ見直し、分からない場合はサーバー会社のマニュアルかサポートを確認することがトラブル短縮につながります。接続が安定して行えることを確認してから、次のディレクトリ構成の確認に進みます。
手順5 ディレクトリ構成とトップページを確認する
ホームページを公開するときは、最初にサーバー側のディレクトリ構成とトップページの扱いを理解することが重要です。 誤った場所にアップロードすると、いつまでもページが表示されません。
ディレクトリ構成で最低限確認したいポイント
代表的なレンタルサーバーでは、公開用フォルダ名が決まっています。FTP接続後、ルート直下にあるフォルダ名を確認しましょう。
| サーバー例 | 公開フォルダ名の例 |
|---|---|
| さくらのレンタルサーバ | www または public_html |
| エックスサーバー | public_html |
| ロリポップ | public_html |
公開フォルダ以外にアップロードしても、ブラウザからは表示されません。
フォルダ階層を変更する場合(例:/lp/配下にランディングページを置くなど)は、URLとの対応も事前に整理しておくと混乱を防げます。
トップページとして認識されるファイル名
多くのサーバーでは、以下のファイル名がトップページとして自動的に読み込まれます。
index.htmlindex.htmindex.php
公開フォルダ直下に、どのファイルをトップページとして表示させるかを決め、ファイル名を統一しておくことが重要です。 既存サイトを差し替える場合は、現状のトップページファイル名(例:index.php)を確認したうえで、新旧ファイルのバックアップとリネーム方針を事前に決めておきましょう。
手順6 ファイルをアップロードし表示を確認する
ファイルのアップロードは、準備してきた内容を実際にインターネット上で公開する作業です。アップロード後の「表示確認」までを1セットとして行うことが重要です。主な流れは次の通りです。
- ローカル環境で最終チェック(リンク切れ、文言、画像サイズなど)
- FTPソフトやファイルマネージャで、本番サーバーの公開用フォルダに接続
- 追加・更新したファイルだけをアップロード(誤って別フォルダを上書きしないよう注意)
- ブラウザで該当URLを開き、表示を確認
- 変更が反映されない場合は、ブラウザのキャッシュ削除・シークレットウィンドウで再確認
- 主要ページ(トップページ、問い合わせ、商品・サービスページ)を一通りクリックし、レイアウト崩れやリンクミスがないか確認
とくに、意図しないファイルの上書きとキャッシュによる「変わっていないように見える」状態がトラブルになりやすいポイントです。作業ログを簡単にメモしておくと、問題が起きた際の原因特定にも役立ちます。
手順7 SSL設定とwww有無の統一を行う
アップロードしたファイルの表示を確認できたら、最後にSSL設定とURLの統一を行うことで、セキュリティとSEOの両面を整えます。
まず、レンタルサーバーの管理画面で「SSL設定」や「無料SSL」「Let’s Encrypt」などのメニューから、対象ドメインにSSLを有効化します。設定反映には数分〜数十分かかることがあるため、完了後に https://ドメイン名 でアクセスし、鍵マークが表示されるかを確認します。
次に、URLを「https」「wwwあり or なし」のどちらかに統一します。方法は主に以下の2つです。
| 統一方法 | 主な手段 | 補足 |
|---|---|---|
| 常時SSL化 | .htaccessでhttp→httpsリダイレクト |
WordPressの場合はプラグイン利用も可 |
| www有無の統一 | .htaccessのリダイレクト設定、またはサーバー機能 |
Google検索コンソールにも代表URLを登録 |
一貫したURLでアクセス・計測・SEO評価を集約することが重要なため、公開直後の段階で必ず設定しておくと、その後の運用がスムーズになります。
FTPソフトの基本設定と操作の流れ

FTPソフトの操作は毎回同じ流れになるため、基本パターンを押さえておくと公開作業のミスを大きく減らせます。最低限、「接続 → アップロード先の確認 → ファイル転送 → 結果確認」の4ステップをセットで認識しておくことが重要です。
一般的な流れは次の通りです。
- FTPソフトを起動し、事前に登録した接続設定を選択してサーバーへ接続する
- 画面左側(ローカル側)でパソコン内の公開したいファイルやフォルダを選択する
- 画面右側(サーバー側)で公開用ディレクトリ(例:
public_htmlやhtdocs)を開く - 目的の場所を確認したうえで、ドラッグ&ドロップや右クリックメニューでアップロードする
- 転送結果ログにエラーがないか、ファイルサイズや更新日時が想定どおりかを確認する
- ブラウザで対象ページを開き、表示崩れやリンク切れがないかチェックする
特に、アップロード先のフォルダを誤ると別サイトを上書きしてしまうリスクがあります。 操作前に「今どのフォルダにいるか」を毎回確認する運用ルールを社内で共有しておくと安全です。
ホスト名やユーザー名など必須項目の入力方法
FTPソフトを利用するには、レンタルサーバーから案内された接続情報を正しく入力することが重要です。代表的な項目と入力の考え方を整理します。
| 項目名 | 意味・入力内容の例 |
|---|---|
| ホスト名(サーバー) | ftp.example.com や sv.xserver.jp など、サーバー会社が指定する接続先ドメインやIPアドレス |
| ユーザー名(ログインID) | サーバー契約時に発行されるアカウント名。管理画面のログインIDとは異なる場合がある |
| パスワード | 上記ユーザー名に対応するFTP用パスワード |
| ポート | 通常は 21(FTP)、22(SFTP)など。指定があれば案内どおりに設定 |
| 接続先のプロトコル | FTP / FTPS / SFTP など、サーバー側の推奨方式を選択 |
最初に行うべきことは、サーバー会社から届いた「サーバー設定情報」や「FTP情報」のメール・管理画面を確認し、上記の各項目を一字一句そのまま転記することです。
入力ミスがあると接続エラーになるため、コピー&ペーストの利用や、半角・全角、余計なスペースの混入などに注意します。設定が複数作れるFTPソフトでは、サイト名(例:自社サイト名)を付けて保存し、いつでも同じ情報で接続できるようにしておくと運用が安定します。
公開用フォルダの場所とアップロード位置の確認
公開用フォルダの場所を誤ると、トップページが表示されなかったり、意図しないURLで公開される原因になります。必ず「どのフォルダにアップロードすべきか」を事前に確認してから作業を開始することが重要です。
一般的なレンタルサーバーでは、公開用フォルダ名は以下のように決められていることが多くあります。
| サーバー例 | よくある公開用フォルダ名 |
|---|---|
| さくらインターネット | public_html |
| ロリポップ | public_html |
| エックスサーバー | public_html または htdocs |
| 企業独自サーバー | www、html など個別設定 |
確認方法としては、サーバーのマニュアルや管理画面の「サイト設定」「ドキュメントルート」「公開フォルダ」の項目を参照します。FTPソフトで接続した直後に表示されるフォルダ一覧の中から、マニュアル記載の公開用フォルダに移動し、その中に index.html や index.php をアップロードする構成が基本です。
複数サイトを同じサーバーで運用する場合は、公開用フォルダ直下にドメインごとのサブフォルダ(例:example.com)が用意されているケースもあります。この場合、「ドメイン用フォルダの中」こそがアップロード位置であり、1つ上の階層に誤ってアップしないことが重要です。
上書きアップロードと削除の扱いに注意する
上書きアップロードや削除は、一度の操作で公開中のページを壊すリスクが高い作業です。特に本番環境では、以下のポイントを必ず意識してください。
上書きアップロード時の注意点
- アップロード前に、ローカルとサーバーの両方で対象ファイル名とパスが正しいかを確認する
- 同名ファイルをアップロードする前に、サーバー側のファイルを必ずバックアップ(ダウンロード)しておく
- テキストや画像を一部差し替える場合も、関連ファイル(CSS、JS、画像フォルダなど)をセットで管理する
- 大量のファイルを一括上書きする場合は、事前にテスト環境で動作確認を行う
削除操作時の注意点
- 不要に見えるファイルでも、別ページやスクリプトから参照されている可能性があるため、すぐに削除せず一旦別フォルダへ退避する方法が安全
- 削除前後で、トップページだけでなく、主要導線ページ(サービス、問い合わせ、商品ページなど)をチェックする
- 不要なバックアップファイルや古いディレクトリを整理する場合も、日付付きでローカルにアーカイブしてから削除する
アップロードや削除を「小さな更新」と捉えず、本番システムの変更作業として事前確認とバックアップを徹底することが、トラブル防止につながります。
公開時によくあるトラブルと原因の切り分け方

公開時のトラブルは、まず「どこで問題が起きているか」を切り分けることが重要です。表示の問題か、サーバー・ネットワークの問題か、設定やファイル構成の問題かを順番に確認すると、原因にたどり着きやすくなります。
代表的な切り分けの観点を整理すると、次のようになります。
| 観点 | 具体的に確認する内容 | 主な原因の例 |
|---|---|---|
| 表示可否 | URLを開くとエラーか白画面か、特定ページだけか | DNS未反映、.htaccessエラー、PHPエラーなど |
| 対象範囲 | すべてのページか、一部ページ・画像だけか | ディレクトリ構成の不整合、ファイル未アップロード |
| 環境差 | 社内PCだけか、スマホや他ネットワークでも起こるか | キャッシュ、社内プロキシ、ファイアウォール制限 |
| 変更履歴 | 直前に行った作業は何か | 上書きアップロードミス、設定変更の誤り |
トラブルが起きた際は、
- まず別ブラウザ・別端末・シークレットモードで再現するかを確認する
- エラー内容(ステータスコードやエラーメッセージ)を必ずメモする
- 「いつから/どの作業の後から」おかしくなったかを整理する
原因の切り分けの精度が上がるほど、制作会社やサーバー会社への問い合わせもスムーズになり、復旧時間の短縮につながります。
トップページが表示されないときの確認項目
トップページが表示されない場合は、原因を「URL」「ファイル名・場所」「サーバー設定」の3つに分けて確認すると、無駄なく切り分けできます。
1. URLとドメインの状態を確認する
- ブラウザのアドレスバーに入力したURLに誤字がないか
http/https、wwwの有無が正しいか- 他のページ(例:
https://example.com/test.html)は表示できるか - サーバーの契約やドメインの有効期限が切れていないか
2. トップページファイル名と場所を確認する
- 公開用フォルダ(多くは
public_htmlやwww)直下に配置されているか - ファイル名がサーバーの仕様に合っているか(一般的には
index.htmlまたはindex.php) - 大文字・小文字の違い(
Index.htmlなど)がないか
3. サーバー設定・エラー状態を確認する
- 403(権限エラー)、404(ファイルなし)、500(サーバーエラー)などのエラーメッセージの有無
- .htaccess でトップページの挙動を変える設定をしていないか
- WordPressの場合、トップページ用固定ページの設定やパーマリンク設定を変更していないか
URL → ファイル名・場所 → サーバー設定の順に確認すると、原因を素早く特定しやすくなります。
画像やCSSが崩れる場合のパス設定の見直し
画像やレイアウトが崩れる場合、多くはファイルパスの指定ミスが原因です。まず、ブラウザの開発者ツール(検証ツール)の「Console」や「Network」タブで、画像やCSSに404エラーが出ていないか確認します。404が出ている場合は、リンク先のパスが実際のファイル位置と一致していません。
主な確認ポイントは次の通りです。
- 絶対パスか相対パスかの整合性:
- 本番URLが
https://example.com/の場合、/images/logo.pngのようなルート相対パスは、そのまま利用可能かを確認します。 ../images/など相対パスを多用している場合は、ディレクトリ構成変更やサーバー側の公開ディレクトリ(public_htmlやhtdocs)の階層差を見直します。- 大文字・小文字の違い:
- サーバー環境では
Logo.pngとlogo.pngが別ファイルとして扱われます。ローカルと同じ名前かを確認します。 - CSS内の
url()指定: - 背景画像などを
url("../img/bg.png")のように指定している場合、CSSファイルの位置からの相対パスになっているかを確認します。
アップロード前後でディレクトリ構成が変わった場合は、HTMLとCSS内のパスを一括で見直すことが、崩れの解消につながります。
アップロードしても更新されない場合の対応
アップロードをしているのに変更が反映されない場合は、原因を切り分けながら確認すると解決しやすくなります。特に、「ブラウザのキャッシュ」「アップロード先の間違い」「ファイル名・階層の不一致」「CMS側の設定」の4点を優先的に確認すると効率的です。
ブラウザとサーバー側のキャッシュを疑う
変更が反映されない場合、まずはブラウザのキャッシュを削除し、シークレットウィンドウや別ブラウザで表示を確認します。CDNやWAFを利用している場合は、管理画面からキャッシュ削除(パージ)を行います。キャッシュが原因のケースは非常に多いため、必ず最初に確認することが重要です。
アップロード先とファイルを再確認する
次に、FTPソフトでサーバーに接続し、該当ファイルが正しいディレクトリ(例:public_html や www など公開用フォルダ)に上書きされているか確認します。
- テスト用ディレクトリに誤ってアップロードしていないか
index.htmlとindex.phpのどちらが優先されているか- 似た名前のファイルが複数存在していないか
をチェックします。同じファイル名でも、アップロードした階層が1つずれているだけで、実際には別ページを更新している状態になるため注意が必要です。
ファイルパスとCMSの設定を見直す
静的HTMLの場合は、ブラウザで表示中のURLと、編集したファイルのパスが対応しているかを確認します。CMS(WordPressなど)の場合は、テンプレートファイルではなく、固定ページや投稿の内容を管理画面側で更新する必要があるケースがあります。
- キャッシュ系プラグインを利用している場合は、一時的に無効化して反映確認を行う
- テーマを複数持っている場合は、編集しているテーマと有効化されているテーマが同じかを確認する
といった点も見直します。
どうしても反映されない場合
上記を確認しても変更が反映されない場合は、
- サーバーのエラーログ(500エラーなど)が出ていないか
- 権限設定(パーミッション)が厳しすぎないか
- 別の簡易なテキスト(例:ページ上部に「test」とだけ記載したHTML)をアップロードして変化が出るか
を確認し、問題の発生箇所を特定します。テスト用の非常にシンプルなファイルで反映状況を確認すると、「サーバー設定の問題」か「個別ファイルの問題」かを切り分けやすくなります。
WordPressサイトが真っ白なときの対処の考え方
WordPressの画面が真っ白になった場合は、原因を切り分けながら落ち着いて対処することが重要です。まず最初に行うべきは、バックアップの有無を確認し、サーバーの管理画面にログインできる状態を確保することです。
代表的な原因と初動の考え方は次の通りです。
- プラグイン・テーマの不具合:直前に追加・更新したプラグインやテーマが原因のことが多いため、FTPやファイルマネージャーから
wp-content/pluginsまたはthemesの該当フォルダ名を一時的に変更し、無効化して状況を確認します。 - PHPバージョンの不整合:サーバー側でPHPを更新したタイミングで発生することがあります。サーバーの管理画面からPHPバージョンを一つ下げて再確認します。
- .htaccessや設定ファイルのエラー:
wp-config.phpや.htaccessを直近で編集した場合は、記述ミスの可能性があります。編集前のバックアップに戻すか、デフォルトの記述に差し替えて確認します。
いずれの場合も、「何を変更した直後に真っ白になったか」を時系列で振り返ると原因にたどり着きやすくなります。自力での復旧が難しい場合に備え、事前に制作会社やサーバー会社のサポート窓口を把握しておくと安心です。
安全に公開するためのバックアップと権限管理

ホームページ公開作業では、バックアップと権限管理をどこまで整えているかが“事故の起こりやすさ”を左右します。 アップロード前後のちょっとした設定ミスや削除操作が、サイト全体の停止や情報漏えいにつながるためです。
まずバックアップは、少なくとも「サーバー上のファイル一式」と「データベース(WordPressなどCMS利用時)」の2種類を取得します。レンタルサーバーの自動バックアップ機能がある場合も、公開前後のタイミングだけは自前で控えを取ると復旧がスムーズになります。
権限管理では、サーバーやFTP、CMSのログイン情報を一元管理しつつ、共有範囲を最小限に絞ります。制作会社には作業に必要なアカウントだけを発行し、「管理者権限」と「更新専用権限」を分けることで、誤操作や情報流出のリスクを抑えられます。退職者や取引終了先のアカウント削除も、公開フローとセットでチェックすると安全性が高まります。
アップロード前に取得しておくべきバックアップ
ホームページ公開や更新の前には、「元に戻せる状態」を必ず確保してから作業することが重要です。公開前に最低限取得しておきたいバックアップは次のとおりです。
| バックアップ対象 | 目的・注意点 |
|---|---|
| Webサイトのファイル一式(HTML/CSS/画像/JS など) | 作業前の状態に戻すために、FTPでローカルへ丸ごとダウンロードして保存します。日付フォルダで管理すると復元しやすくなります。 |
| CMS(WordPress など)のデータベース | 記事や固定ページ、設定が保存されているため、プラグインやテーマ更新前にダンプ(エクスポート)を取得します。 |
| サーバー設定の情報(.htaccess、各種設定画面のスクリーンショット) | リダイレクトやSSL設定を変更する前に、現状を控えておくことで、設定ミス時にすぐ戻せます。 |
| DNS/ドメインの設定内容 | ネームサーバーや各種レコードを変更する前に、現在の設定をスクリーンショットやテキストで保存します。 |
「どの時点の状態を残したバックアップか」をファイル名やメモで明示することで、トラブル発生時の復旧時間を大きく短縮できます。
社内と制作会社で管理すべき情報を分ける
社内と制作会社のどちらが何を管理するかを明確に分けておくと、トラブル時の対応が早くなり、情報漏えいリスクも下げられます。特に「契約や支払いに関わる情報」と「実務作業に必要な情報」は必ず分離して管理することが重要です。
代表的な分担例は次の通りです。
| 区分 | 社内で必ず管理すべき情報 | 制作会社に共有してよい情報 |
|---|---|---|
| 契約・支払い | レンタルサーバー契約アカウント、ドメイン管理アカウント、クレジットカード情報、請求書送付先 | 原則共有しない(必要な場合はサブアカウントや代理ログイン機能を利用) |
| アクセス権限 | 本番サーバーの管理者アカウント、Googleアナリティクス/サーチコンソールのオーナー権限 | FTPユーザー(作業用)、CMSの編集者・制作者アカウント |
| 設定情報 | 本番環境のURL構成ポリシー、バックアップ方針、運用ルール | サーバー接続先情報、ディレクトリ構成、テスト環境のURL |
ポイントは、
- 本契約アカウントや支払いに紐づく情報は社内のみで管理する
- 制作会社には、作業に必要な範囲のアカウント(FTP用の限定ユーザー、WordPressの編集者権限など)だけを発行する
- 担当者変更や制作会社変更に備え、権限一覧と引き継ぎ手順をドキュメント化しておく
このように情報を整理しておくと、ホームページのアップロードや更新作業を安心して外部に委託しつつ、事業者側でコントロールを維持しやすくなります。
誤操作を防ぐためのアカウントと権限の設計
誤操作によるファイル削除や設定変更を防ぐためには、「誰が・どこまで・どの環境で」操作できるかをあらかじめ決めておくことが重要です。特にサーバーやWordPressの管理権限は、安易に「全員管理者」にしないことが基本方針になります。
代表的なアカウントと権限設計の例は次の通りです。
| 区分 | 想定する担当者 | 権限レベルの例 | 主な操作 | ポイント |
|---|---|---|---|---|
| 本番サーバー(FTP/SSH) | 社内責任者・制作会社リーダー | フル権限は最小人数 | ファイル編集・設定変更 | IDの共用を避け、操作ログを追えるようにする |
| CMS管理画面(WordPressなど) | 社内担当・制作会社 | 管理者 / 編集者 / 寄稿者など | 記事更新・デザイン変更 | 更新担当者には「編集者」権限までに制限する |
| ステージング環境 | 制作会社・一部社内担当 | 本番と同等か少し広め | テスト・検証 | 本番とIDを分けて、誤って本番更新しないようにする |
特に重要なのは、「契約情報・支払い情報を持つアカウント」と「日々の運用でログインするアカウント」を分けることです。契約アカウントは社内の限られた管理者だけが保持し、制作会社は運用用アカウントで作業する設計にしておくと、解約・乗っ取り・無断設定変更のリスクを抑えられます。
ステージング環境を使った安全な公開手法

ステージング環境は、本番公開前に動作確認を行うための「テスト用の公開環境」です。直接本番にアップロードせず、必ずステージングで検証してから反映することで、レイアウト崩れやリンク切れ、機能不具合のまま公開してしまうリスクを大きく減らせます。
ステージング環境を使った安全な公開の基本は、次の流れです。
- 本番とほぼ同じ構成のステージング用サイトを用意する(サブドメインや別ディレクトリなど)
- 制作物のアップロードやWordPressのテーマ・プラグイン更新を、まずステージングに適用する
- デザイン、フォーム送信、計測タグ、スマホ表示などを社内・関係者で確認する
- 問題が無ければ、本番環境へ同じ変更を反映する、またはサーバーの機能で「ステージング→本番」反映を実行する
更新頻度が高いコーポレートサイトやWordPressサイトほど、ステージング環境の有無が事故発生率を左右します。 小規模な改修でも、本番での「動かしてみないと分からない変更」はできる限りステージングで検証してから行う運用を徹底すると安全です。
テスト用環境を用意するメリットと構成例
ステージング(テスト用)環境は、公開前に不具合を洗い出す「安全な実験場」です。本番環境とできるだけ近い構成で検証することで、レイアウト崩れやフォーム不具合、速度低下などを事前に発見できます。特に、リニューアルや機能追加など影響範囲が大きい更新では、ステージング環境の有無がトラブル発生率を大きく左右します。
代表的な構成例は次のとおりです。
| パターン | 想定規模・用途 | 構成イメージ | ポイント |
|---|---|---|---|
| サブドメイン型 | 中小〜中堅サイト | stg.example.com を本番と同一サーバー上に用意 |
本番と同じサーバー・PHPバージョンで検証しやすい |
| サブディレクトリ型 | 小規模サイト、静的サイト | example.com/stg/ 配下にテスト一式 |
手軽だが、本番とURL構造が一部異なる点に注意 |
| 別サーバー型 | アクセスが多いサイト、EC | 開発用サーバーに stg.example.com を構築 |
本番に負荷をかけずテストできるが、構成差異が出やすい |
いずれの構成でも、検索エンジンにインデックスさせないために、ベーシック認証やIP制限、noindex設定などのアクセス制限を必ず行うことが重要です。
ステージングから本番へ反映する基本パターン
ステージング環境から本番環境へ反映する方法は、大きく分けて3つのパターンがあります。どのパターンを採用するかを決めて、社内・制作会社間で運用ルールとして共有しておくことが重要です。
| パターン | 概要 | 向いているケース |
|---|---|---|
| 1. FTPで手動反映 | ステージングで確認後、変更したファイルだけをFTPで本番にアップロード | 小規模サイト、更新頻度が低い場合 |
| 2. 管理画面の「複製・公開」機能 | CMSやレンタルサーバーの機能で、ステージングから本番へ一括コピー | ノーコードCMSや一部レンタルサーバー利用時 |
| 3. Git/自動デプロイ | Gitリポジトリへのプッシュをトリガーに、本番へ自動反映 | 開発者が関わる中〜大規模サイト |
いずれのパターンでも、
- 反映前にステージング環境で表示・動作確認を実施する
- 反映直前に本番のバックアップを取得する
- 反映後すぐに本番環境で主要ページのチェックを行う
という流れは共通です。まずは現状の運用体制に合うパターンを選び、将来的に運用負荷が高まってきた段階で、より自動化された方法への移行を検討すると効率的です。
公開後すぐに行いたい表示と計測のチェック

公開直後の数時間は、表示と計測の不具合を早期に発見する重要なタイミングです。最低限、表示確認・計測タグの動作・重要導線の3点を即チェックすることが重要です。
公開直後にチェックしたい項目一覧
| 観点 | チェック内容 | 確認方法の例 |
|---|---|---|
| 表示 | トップページが正しいURLで表示されるか | PCブラウザで https://ドメイン/ を直接入力 |
| 表示 | 主要下層ページ(サービス、料金、問い合わせなど)がリンク切れなく表示されるか | ナビゲーションから1クリックでたどれるページを順番に開く |
| 動作 | 問い合わせフォームや資料請求フォームが送信できるか | テスト送信を行い、完了画面・通知メールの到達を確認 |
| 動作 | 外部リンク(決済、予約システム、外部ブログなど)が正しく遷移するか | 重要な外部サービスへ実際に遷移してみる |
| 計測 | Googleアナリティクスでリアルタイム計測がされているか | 自分のアクセスがリアルタイムレポートに反映されるか確認 |
| 計測 | Googleタグマネージャーや広告タグが発火しているか | Tag Assistantやデベロッパーツールでタグの発火を確認 |
| セキュリティ | http でアクセスした場合も自動的に https に転送されるか |
http://ドメイン でアクセスしてリダイレクトを確認 |
公開後24時間以内に、上記の基本項目だけでもチェックしておくことで、大きな機会損失や計測漏れを防げます。 そのうえで、次の見出しで扱うブラウザ別・デバイス別の詳細な表示確認に進むと効率的です。
主要ブラウザとスマホでの表示確認ポイント
主要な確認対象は「PCの主要ブラウザ」と「スマートフォン(iOS/Android)」です。最低限、Chrome・Safari・Firefox・Edgeと、iPhone・Androidの実機またはエミュレータでの確認を行うことが重要です。
代表的なチェックポイントを整理すると、次のようになります。
| 項目 | PCブラウザでの確認 | スマホでの確認 |
|---|---|---|
| レイアウト崩れ | ヘッダー・メニュー・本文・フッターが意図した位置に表示されているか | 1カラム表示になっているか、横スクロールが発生していないか |
| 文字サイズ | 拡大しなくても読める大きさか | 小さすぎないか、行間が詰まりすぎていないか |
| 画像表示 | ロゴ・メインビジュアル・商品画像が欠けずに表示されるか | Retina端末で粗く見えないか、ファイルサイズが重すぎないか |
| ナビゲーション | ホバー時の動きやドロップダウンメニューが機能するか | ハンバーガーメニューの開閉、タップしやすいボタンサイズか |
| フォーム | 入力~送信までエラーなく動くか | キーボード種別(数字入力など)が適切か |
さらに、PageSpeed Insightsなどでモバイル表示速度を確認し、読み込みが極端に遅いページがないかを公開直後に把握しておくことが、離脱率やSEOの観点からも有効です。
Googleアナリティクスとサーチコンソール設定
ホームページを公開した直後からデータを蓄積するために、Googleアナリティクス(GA)とGoogleサーチコンソール(GSC)の初期設定は必須です。公開後しばらく経ってから設定すると、過去分のデータは基本的に取得できません。
まずGoogleアカウントでGAとGSCの両方にアクセスし、プロパティ(GA4)とプロパティ(GSC)を新規作成します。GAでは「測定ID(G-xxxx)」を発行し、タグを全ページに設置します。HTMLサイトの場合は<head>内に直接タグを貼り付け、WordPressの場合は公式プラグインやタグマネージャーを利用すると管理しやすくなります。
GSCは、ドメイン単位かURLプレフィックスのどちらかでプロパティを作成し、推奨のDNSレコード登録、もしくはGA連携やHTMLタグによるサイト所有権の確認を行います。GAで集客・行動・コンバージョンを、GSCで検索キーワードや掲載順位を把握することで、公開後の改善施策を客観的なデータに基づいて判断できるようになります。
今後の改善に向けて押さえたい運用の基本視点
ホームページを公開して終わりにすると、成果は頭打ちになります。公開後は「仮説→計測→改善」を継続する運用サイクルを回すことが重要です。最低限、次の視点を押さえておくと判断がしやすくなります。
| 視点 | 目的 | 具体的な確認・改善例 |
|---|---|---|
| 集客(どこから来たか) | 効果的な流入経路を伸ばす | 検索・広告・SNS・メールなど別にセッション数とCV数を確認し、費用対効果の低い経路は見直す |
| コンテンツ(何を見ているか) | 強い・弱いページを見極める | PV・離脱率・滞在時間を見て、読まれていないページの導線や内容を改善する |
| コンバージョン(成果が出ているか) | 問い合わせや資料請求を増やす | CVRが低いフォームや導線を特定し、入力項目削減やCTAの配置・文言をテストする |
| 技術・UX(快適に見られるか) | 離脱要因の排除 | 表示速度、モバイル表示、404エラー、SSLエラーを定期確認し、技術的な不具合を早期に修正する |
運用のポイントは「毎月見る指標」と「四半期ごとに考える施策」をあらかじめ決めておくことです。数字を定点観測しながら、仮説を小さく試し、効果が出た改善だけを標準化すると、無理なく成果につながります。
本記事では、ホームページ公開の全体像から、サーバー・ドメイン・SSLの準備、FTPによるアップロード手順7つ、トラブル対応、バックアップや権限設計、ステージング環境の活用までを整理しました。公開作業を「なんとなくの操作」ではなく、手順とチェックポイントを押さえた再現性のあるフローとして運用できれば、制作会社任せにならず、安全かつ確実にWebサイトを公開・改善していく判断がしやすくなります。



