Ameba Owndにはアメブロのような“非公開ボタン”が存在せず、robots.txtやBasic認証も触れません。「一時的にサイトを閉じたい」「移行前に検索結果から消したい」と悩む人向けに、Ownd内でできる暫定対処とWordPress・Wixなど代替CMSの休止機能を比較し、SEOを崩さず安全に再公開するポイントまで解説します。
目次
Ameba Owndに非公開機能がない理由
Ameba Owndは「ノーコードで誰でもすぐ公開できる」ことを前提に開発されたSaaS型CMSです。ページ閲覧が発生するとリクエストはOwnd側の共有サーバーで処理され、ユーザーにはサーバーディレクトリへの書き込み権限が一切ありません。そのためWordPressのように.htaccessでBasic認証を掛けたり、ルート階層にrobots.txtを置いてクロールを遮断したりする機構が根本的に用意されていません。Owndチームはセキュリティ確保とパフォーマンス均一化を優先しており、個別ユーザーごとにサーバー設定を変えられる余地を認めると、全体の稼働安定性が損なわれるリスクがあるためです。
また、Owndの管理画面は公開＝オンライン、下書き＝オフラインという二者択一で設計されています。下書きに戻したページはURLごと404応答になりますが、サイト全体を一括で下書きへ切り替えるボタンは搭載されていません。これは「レイアウト調整中でも一部ページは公開し続けたい」というライトユーザーの要望を優先したUIのためです。もしサイト全体をクローズしたい場合は、各ページを手動で下書きへ戻すか、独自ドメイン運用者であればDNS側でリダイレクトを掛けるしか方法がありません。下表にOwndの公開モデルと非公開制御の可否を整理しました。
| 操作項目 | ユーザー側での可否 |
|---|---|
| robots.txt編集 | × — サーバー階層にアクセス不可 |
| .htaccess Basic認証 | × — Apache設定領域なし |
| ページ単位下書き | ◎ — 管理画面で切替 |
| サイト全体非公開 | △ — 全ページ下書き手動/外部リダイレクトで対応 |
このようにOwndは「簡単公開」に最適化されている一方、「完全非公開」には向かない構造というわけです。
サーバー権限・robots.txt編集不可の構造
まずサーバー権限について解説します。WordPressを自前サーバーに置くと、ディレクトリ直下に.htaccessやrobots.txtを設置し、アクセス制御やクロールルールを自由に書けます。しかしOwndはマルチテナント方式で運用され、ユーザーデータはデータベースで論理分割されるのみです。ファイルシステムは共有のため、個別ユーザーが. htaccessを上書きすると他ユーザーに波及する恐れがあり、運営側はその権限を開放していません。
robots.txtはサイトルートに置くことで検索エンジンが最初に読み取りますが、Owndではルート自体が共通サーバーの配下にあり、ユーザーがアップロードしたファイルは/user/12345/のようなサブディレクトリへ格納されます。そのためユーザーフォルダにrobots.txtを置いてもクロール制御は効きません。さらにBasic認証を掛ける場合もApacheの設定が必要ですが、これも共有サーバーでは安全上不可です。
- robots.txtでDisallow: /を指定しても検索エンジンはルートしか読まないため無効
- JavaScriptでリダイレクトしてもクローラーはJS解釈後にページを取得しうる
- パスワード保護はCloudflare Accessなど外部CDN上で実装するしかない
アメブロ「ブログ非公開」との仕様差
同じサイバーエージェント系のサービスでも、アメブロにはブログ全体を一時非公開にするスイッチが存在します。これはアメブロがブログ単位でサブドメインを割り当て、ルーティングも個々のブログIDで切り替えているため、運営側が「特定ブログ宛のリクエストをログイン画面へリダイレクトする」実装が容易だからです。
対してOwndはサイトURLがhttps://xxxx.amebaownd.comのように一見サブドメインですが、内部的にはPath Based Routingでテンプレートを呼び出しています。そのためOwnd側で全リクエストを止めると他ユーザーのサイトにも影響が及ぶため、全体非公開機能は提供されていません。
【機能比較表】
| 機能 | アメブロ | Ameba Ownd |
|---|---|---|
| 全体非公開 | ◎ ボタン1つ | × 非対応 |
| 記事単位非公開 | ◎ 下書きに戻す | ◎ 下書き・公開切替 |
| パスワード制限 | × | × (外部サービスで代替) |
- アメブロの非公開機能はURLごと認証ページへ302リダイレクト
- OwndはURL単位に404返却しかできず、SEOシグナルは保持される
- Owndで完全非公開に近づけるには独自ドメイン＋CDN側でリダイレクト設定
- アメブロとOwndはシステム構造が異なるため、同じ感覚で操作しない
- Ownd利用者は非公開ではなく「下書きで隠す」「外部で遮断」の二択
- 本格的な休止・リニューアルはWordPressやWixなど休止機能付きCMSを検討
Ownd上で“見せない”ための暫定対処ワザ
Ameba Owndにはブログ全体を一括で停止するスイッチが無いものの、「検索や通常閲覧ではまず気づかれない状態」に近づけるテクニックは存在します。コアとなるのは〈①全記事を下書きへ戻す〉〈②グローバルナビとサイトマップを非表示にする〉の組み合わせです。これによりトップページを除く既存URLは 404 応答となり、内部導線も遮断されるため到達経路がほぼゼロになります。加えて独自ドメインを運用している場合は DNS を Cloudflare に委譲し、Page Rules か Access で閲覧を自分だけに限定する方法が取れます。以下の表で“見せない度”と作業コストを比較し、目的とスケジュールに合った方法を選択しましょう。
| 対処法 | 見せない度 | 作業コスト |
|---|---|---|
| 全記事下書き | ★★★☆☆（内部リンク遮断） | 低：10〜15分 |
| ナビ・サイトマップ非表示 | ★★☆☆☆（導線カット） | 低：5分 |
| Cloudflareリダイレクト | ★★★★★（外部遮断） | 中：30分＋DNS反映 |
全記事下書き＋ナビ非表示で実質クローズ
まず最速で実行できるのが全記事を「下書き」に戻す方法です。ダッシュボードの「記事一覧」でチェックボックスを一括選択し、アクションメニューから〈下書きに戻す〉をクリックするだけで完了します。記事URLへアクセスすると 404 が返り、検索結果クリック時も「ページが存在しません」と表示されるため、読者はほぼ離脱します。ただしトップページが残っていると「記事が無い空サイト」が見えてしまうので、ナビゲーションバーとサイトマップを同時に非表示にしましょう。
\
- 記事一覧で「すべて選択」→下書きに戻す（※最大100件ずつ）
- デザイン＞ナビメニュー設定で全リンクの目アイコンをOFF
- サイドバー「サイトマップ」ウィジェットを削除または非表示
- トップのヒーロー画像を“工事中”バナーに差し替え
- Search Consoleで「URL一時削除」を申請（24時間以内反映）
- 公開状態の記事が多い場合は100件上限で複数回操作が必要
- 下書き化しても旧URLはしばらくインデックスに残るため、検索結果のクリックは404になる
- 再公開時は記事ごとに「下書き→公開」に戻すだけで元に戻る
この方法のメリットは「作業がすぐ終わる」「再公開もワンクリック」である点ですが、完全に外部から見えなくするわけではないこと、インデックス削除が遅延する点には注意しましょう。
独自ドメイン利用者向けCloudflareリダイレクト
独自ドメインで Ownd を運用しているなら、DNS を Cloudflare に委譲して外部レイヤーでアクセス制限を掛けるのが最も確実です。無料プランでも Page Rules を３本まで設定できるため、ドメイン全体を任意の LP に301リダイレクトするか、Cloudflare Access でメールアドレス認証を通過したユーザーだけ閲覧可能にできます。ここでは「一時的に工事中LPへ転送する」手順を解説します。
\
- Cloudflare登録→ドメイン追加→ネームサーバー変更
- Page Rules → 「*example.com/*」を入力
- 設定項目で Forwarding URL (Status Code: 301) を選択
- 転送先に「https://example.com/maintenance.html」を入力
- Save and Deploy → DNS反映を待つ（最大30分）
- SSL/TLSが「フル（厳格）」になっているか確認し、リダイレクトループを防ぐ
- Googlebot は 301 を認識して評価を転送するため、SEOダメージは最小
- メンテナンス完了後は Page Rules をDisableにし、すぐ再公開
Cloudflare Accessを使う場合は、メールアドレスやGoogleアカウントでログインしたユーザーだけに閲覧を許可できます。これにより開発チームやクライアントとURLを共有しつつ、一般公開を防げるため、リブランディング準備やデザイン大幅改修時に重宝します。
\
- DNS切替中は一時的に旧 NS へアクセスするユーザーが存在
- 切替作業は深夜帯に実施し、SNSで事前告知するとトラブルを防げる
- DNS TTL を30分以下に下げてから切替し、反映速度を上げる
独自ドメイン×Cloudflareは少々テクニカルですが、完全非公開に最も近い状態を無料で実現でき、復旧もスイッチひとつという強力な選択肢です。
完全非公開を実現する他プラットフォーム比較
Ameba Ownd上では“完全非公開”をボタン一つで切り替えることができませんが、WordPressやWixなど一部のCMSは「メンテナンスモード」「休止モード」を標準もしくは公式プラグインで備えています。しかも 301 リダイレクトや Basic 認証と組み合わせれば、検索順位や被リンク評価を保持したまま閲覧をブロック可能です。下表では主要プラットフォームの非公開手段とカスタマイズ自由度、月額コストを比較しました。まずは “作業負荷を下げつつ非公開にしたいのか” それとも “時間を掛けても柔軟性を確保したいのか” を決め、要件に最も合致するサービスを選定しましょう。
| プラットフォーム | 非公開方法 | 月額コスト目安 |
|---|---|---|
| WordPress | メンテナンスプラグイン／.htaccess Basic認証 | サーバー500〜1,000円＋ドメイン |
| Wix | 休止モード（パスワード保護／閲覧制限） | 1,000〜2,500円 |
| note Pro | 限定公開設定（リダイレクト付き） | 5,000円〜 |
| STUDIO | メンテナンスページ機能＋パスワード保護 | 980〜2,480円 |
WordPress＋メンテナンスプラグインの柔軟性
WordPressはサーバー設置型なので .htaccess や robots.txt を自由に編集でき、プラグインを使えばワンクリックで「503 Service Unavailable」を返すメンテナンスモードを有効化できます。代表的なプラグインは Maintenance と Coming Soon & Maintenance Mode の２つ。無料版でもロゴ／背景／カウントダウンタイマーをカスタムでき、Basic 認証と併用すれば検索エンジンにもユーザーにも完全非公開を徹底できます。さらに SeedProd（有料）を使うとメンテナンス中でも LP を個別公開できるため、「一部ページだけ集客を継続、残りは工事中」というハイブリッド運用も可能です。
- サーバーパネルで独自 SSLを有効化し常時 https に統一
- Maintenance プラグインをインストール→「503＋Retry-After」ヘッダー設定
- .htaccess に
AuthType Basicを追記し管理画面と公開画面を二重ロック - Search Console で URL一時削除を申請しキャッシュを速やかに消去
- メリット：自由度とプラグイン数が圧倒的／再公開もスイッチ一つ
- デメリット：サーバー保守が自己責任、学習コストがやや高い
初めての方は「エックスサーバー WordPressクイックスタート」を使えば 10 分で環境が整うため、難易度を大幅に下げられます。
Wix／note Pro／STUDIOの休止モード活用ポイント
コード編集に不慣れ、かつ UI ベースで素早く非公開にしたい場合は、クラウド型 CMS の休止モードが有効です。
【◯◯◯ 休止モード３サービス比較】
- Wix
ダッシュボード→「サイトを休止」→チェックを入れるだけで閲覧不可。ログイン中の管理者だけはプレビュー可能。
★制限：無料プランは Wix 広告が残るので、ブランドを気にするなら有料必須。 - note Pro
「限定公開」設定で全ページを非公開に切り替え、必要な記事だけ URL を個別共有可能。
★制限：デザインカスタマイズがほぼできず、ブログ型に特化。 - STUDIO
「メンテナンスページ ON」にすると全 URL がカスタム HTML LPへ転送。パスワード保護も併用可能。
★制限：CMS（ブログ）機能はβ版、データエクスポート不可。
- Wix は「SEO設定」を休止中も編集できるが、robots.txt は自動生成のまま。
- note Pro はドメインマッピングが上位プランのみ、費用対効果を確認。
- STUDIO は静的サイト生成型のため、休止中もホスティング料金が発生。
移行・再公開時に押さえるSEO＆運用チェック
Ameba Ownd から別 CMS へ移行する、あるいは一時休止したサイトを再公開する──どちらの局面でも最大のリスクは「検索評価のリセット」と「リンク切れによるユーザー離脱」です。ページを丸ごと消したり URL を変えたりすると、被リンクとインデックスが分断されて検索順位が急落します。そこで重要になるのが ①301 リダイレクト で評価を継承し、 ②Search Console でクロールとキャッシュ状況を監視する二段構えの運用です。さらに移行前後で Core Web Vitals や構造化データの整合性を取り、クローラビリティを落とさないことも忘れてはいけません。以下の h3 では「設定手順」と「監視フロー」を具体的に示すので、チェックリスト化して作業漏れを防ぎましょう。
| 項目 | 目的 |
|---|---|
| 301 リダイレクト | 旧 URL から新 URL へ評価とユーザーを転送 |
| Search Console 設定 | クロール状況とエラーをリアルタイム確認 |
| インデックス監視 | 順位・CTR 変動を追跡しリライト時期を判断 |
301リダイレクトとSearch Console設定手順
301 リダイレクトは「恒久的な移転」を示す HTTP ステータスで、旧 URL の評価をほぼ 100 ％ 新 URL に継承できます。独自ドメインなら .htaccess やサーバーパネルで、サブドメインなら Cloudflare Page Rules で設定しましょう。リダイレクトが完了したら Search Console で２つの操作 を行います。①新しいプロパティを追加して XML サイトマップを送信、②旧プロパティの「アドレス変更」で新ドメインを指定。これにより Googlebot が新 URL を優先クロールし、インデックス更新を早められます。
- 旧ドメインに
Redirect 301 / https://new.com/を設定 - 新ドメインで Search Console プロパティ作成→サイトマップ送信
- 旧ドメイン側 SC「設定＞アドレス変更」で新ドメインを指定
- GA4 の測定 ID を新サイトに差し替え、データ連続性を確保
- 移行当日は 404 ゼロを目指し、Screaming Frog で一括クロール
- クローラビリティ改善のため、旧サイトの robots.txt で Allow を維持
- SSL 証明書を新サーバーで早めに発行し、HTTPS ミスマッチを防止
設定直後は順位が一時低下することがありますが、301 が正しく機能していれば 2〜4 週間で戻るのが一般的です。
コンテンツ移行前後のインデックス監視フロー
移行作業後に必ず行うべきなのが「インデックス監視」です。移行前と移行後で検索パフォーマンスがどう変化したか、毎週データを比較し、問題があればリライトや内部リンク修正を行います。ここでは GA4 と Search Console を使った実践フローを示します。
- 基準値取得：移行前 30 日間の GA4・SC データをエクスポート
- 週次レポート：Looker Studio で PV・CTR・平均順位を自動更新
- 異常検知：PV 30％↓ or 平均順位 5 位↓ を閾値にアラート
- 原因特定：SC「カバレッジ」エラーと GA4「参照元」を照合
- 対策実行：リンク修正・タイトル再最適化→再リクエスト
- GA4 の「経路探索」で新 URL への流入経路を可視化し、離脱点を発見
- SC の「ページエクスペリエンス」で LCP・CLS が悪化していないかチェック
- 移行前に noindex を入れていた場合、再公開時に必ず削除し再クロールを促進
| 監視指標 | 理想値(移行後) | 要アラート閾値 |
|---|---|---|
| 平均CTR | 移行前±5％ | −10％ |
| 平均掲載順位 | 移行前±1位 | −5位 |
| 404数 | 0 | 1 以上 |
これらを習慣化すれば、移行ミスによる流入ロスを最小限に抑え、再公開後の安定運用へスムーズに移行できます。
まとめ
Ownd単体では全体非公開は不可能ですが、①全記事下書き＋ナビ非表示、②独自ドメインならCloudflare遮断で応急処置が可能。長期休止やリブランディングにはWordPressのメンテナンスプラグインやWix休止モードへ移行するほうが安全です。移行時は301リダイレクトとSearch Consoleの一時削除を併用し、インデックス変動を週次で監視しましょう。
<meta name="robots" content="noindex">を全ページに挿入→ 既にインデックスされたURLは残り続ける
→ 個別記事URLは閲覧可能なまま