Cookie を使用しないドメインの使用方法: 完全ガイド

公開: 2023-01-03

あなたのウェブサイトは、パフォーマンスの低下やネットワーク トラフィックの増加に悩まされていませんか? Cookie が原因であることが多い場合、効果的な解決策の 1 つは、Cookie を使用しないドメインを使用することです。

クッキーは私たちのオンライン エクスペリエンスの主要な基盤の 1 つですが、その名前が示すように常に美味しいとは限りません。 サードパーティの Cookie に関するプライバシーとセキュリティの問題以外にも、サイトの画像やその他の静的コンテンツに自動的に添付される Cookie は、ページのパフォーマンスに深刻な影響を与える可能性があります。

ありがたいことに、Cookie のないドメインを使用することで、自重 (この場合はデッド Cookie) を減らすことができます。 この完全なガイドでは、Cookie を使用しないドメインの基本、それらが非常に役立つ理由、およびそれらを使用するように WordPress サイトを構成する方法を確認します.

しかし、最初に、デジタル Cookie jar に手を伸ばして、ドメインが Cookie をどのように使用しているか (良くも悪くも) を詳しく見てみましょう。

Cookie を使用しないドメインとは?

Cookie を使用しないドメインは、ユーザーのブラウザーに Cookie を送信しない Web サイトの一部です。

しかし、常に Cookie を送信しないのはなぜですか? 結局のところ、ユーザーにできるだけ多くの Cookie を与えるのは礼儀正しいのではないでしょうか?

必ずしも。 Cookie を使用しないドメインについて話している場合、もちろん HTTP Cookie のことを指しています。 私たちのお気に入りの焼き菓子とは異なり、HTTP Cookie は Web サイトがユーザーのブラウザーに送信するデータの小さなパケットです。 あまり美味しいものではありませんが、Web サイトが次に訪問したときにユーザーを「記憶」できるようにするのに非常に役立ちます。

ただし、実際の Cookie と同様に、提供する HTTP Cookie が多すぎないようにする必要があります。 すぐにわかるように、訪問者はいくつかのクッキーを好みます。

あなたのウェブサイトは、パフォーマンスの低下やネットワーク トラフィックの増加に悩まされていませんか? Cookie を使用しないドメインが解決策になる可能性がありますClick to Tweet

HTTP クッキーとは?

HTTP Cookie は Web 上のどこにでもあります。

Web サイトにアクセスするたびに、Web サイトからブラウザーに Cookie を保存するように求められる可能性が高くなります。 Web サイト自体とアクセスしたページに関する情報に加えて、Cookie には、ユーザーとブラウザーに関連付けられた個人識別子が含まれています。 この識別子により、既にそのページにアクセスしたことがあるかどうかを Web サイトが「記憶」することができます。

この Cookie 交換がどのように機能するかを詳しく見てみましょう (ネタバレ注意: 魅力的な枝編み細工品バスケットやガール スカウトは関係ありません)。

Web サイトが HTTP Cookie をユーザーの Web ブラウザーに送信する方法
Web サイトが HTTP Cookie をユーザーの Web ブラウザーに送信する方法

上の画像に示すように、交換は 3 つのステップに分けることができます。

  1. ブラウザが Web ページをリクエストします。 ブラウザのアドレス バーにアドレス (「kinsta.com」などのドメイン URL など) を入力するか、Web リンクをクリックすると、ブラウザは HTTP 要求を生成し、Web サイトにページを表示したいことを伝えます。 このリクエストは、Web サイトとそのページをホストする Web サーバーに送信されます。
  2. Web サーバーはページと Cookie を送信します。 リクエストを受け取ると、Web サーバーはリクエストされたページと特定の情報を含む Cookie を返します。 前述したように、この Cookie にはほとんどの場合、ユーザーとブラウザーの個人識別子が含まれています。
  3. ブラウザは、同じサーバーから別のページをリクエストします。 ここで、e コマース サイトの「ショップ」や「会社概要」など、Web サイトの別のページへのリンクをクリックしたとします。 ここで、ブラウザーは別の要求を Web サーバーに送信し、最初に与えられた Cookie を送信します。 Web サーバーがこの要求を受信すると、以前に送信した Cookie を確認し、ユーザーが既にアクセスしたことを記憶します。 その情報を使用して、Web サーバーは、アクティブなログインやショッピング カート内のアイテムの維持など、よりパーソナライズされたエクスペリエンスを提供できます。

さまざまな目的のためのさまざまな Cookie もあります。 上記の例では、セッション管理に関与する Web サーバーは、ログインまたはショッピング カートのアイテム、つまり Web サイトでの個々のセッションを維持します。 同様に、Cookie を使用して、最近の注文、閲覧したアイテム、さらにはターゲットを絞った広告を表示するなど、パーソナライズされたエクスペリエンスを提供することもできます。

どこに行ってもクッキーがもらえるのはいいことのように聞こえるかもしれませんが、それがすべてというわけではありません。 次のセクションで説明するように、ウェブサイトがあまりにも多くの Cookie を配信することは実際にあり得ます。

ドメインによる HTTP Cookie の使用方法

個人識別子は HTTP Cookie の非常に重要な用途の 1 つですが、それだけではありません。 実際、Cookie は、よりパーソナライズされた Web エクスペリエンスの提供、ターゲットを絞ったコンテンツの配信など、さまざまな目的で使用できます。

プライバシーを侵害するために Cookie がどのように使用される可能性があるか
プライバシーを侵害するために Cookie がどのように使用される可能性があるか

Web サイトとブラウザーが HTTP Cookie を交換してあなたを「記憶」する方法については既に説明しました。 ログイン セッションを維持したり、ショッピング カートのアイテムを表示したりするのに役立ちますが、Cookie はさらに悪質な (またはまったく迷惑な) 目的で使用される可能性があります。

ドメインが HTTP Cookie を使用する最も一般的な方法のいくつかを次に示します。

  • セッション管理。 あなたはすでにこれを知っています。 セッション管理は、ユーザーが特定のアクションを繰り返さなくて済むようにする一貫したユーザー エクスペリエンスを提供することが唯一の目的であるため、HTTP cookie の最も「安全な」使用法と見なされることがよくあります。 以前のアクティビティを見ると、一部のユーザーにプライバシー上の懸念が生じる可能性がありますが、比較的害はありません. 本当のプライバシーの問題は、追跡に Cookie が使用される場合に発生します。これについては、後ほど説明します。
  • パーソナライゼーション。 セッション管理を使用して、ユーザーの好みやアクティビティに基づいて Web ページをパーソナライズすることもできます。 たとえば、選択した言語を選択すると、ユーザーは次回の訪問時に同じ言語で Web サイトを表示できるようになり、毎回言語を変更する必要がなくなります。 また、Cookie を使用すると、さまざまな Web ブラウザーの特定の要件に Web サイトを適応させることもできます。
  • 追跡。 クッキーには物議を醸す側面もあります。 お使いのブラウザは Web サイトが提供する Cookie を保存するため、それらの Cookie を使用して、Web 上のあらゆる場所であなたを追跡できます。 たとえば、ブラウザに追跡 Cookie を提供する Web サイトにアクセスすると、そのページにアクセスしたことを Web 上の提携広告主に知らせることができます。 広告主がこの Cookie に気付くと、元の Web サイトのターゲットを絞った広告を表示したり、サイバー攻撃のベクトルとして使用することさえできます。 いずれにせよ、Cookie を追跡すると、「フォローされている」ように感じられる可能性があります。これには、多くの倫理的およびプライバシー上の懸念が伴います。

ありがたいことに、ほとんどの HTTP Cookie はセッション管理とパーソナライズに使用されます。 ただし、最も無害な Cookie でさえ、問題を引き起こす可能性があります。

これまで、1 つのページが 1 つの Cookie を送信するというアイデアについて説明してきました。 実際には、通常、1 つのページが複数の Cookie を送信します。多くの場合、ページ要素 (HTML、画像ファイルなど) ごとに 1 つです。 これらの Cookie の一部はセッション管理とパーソナライゼーションに必要ですが、多くはそうではありません。

その結果、あまりにも多くの Cookie を送信する可能性があり、これがいくつかの問題を引き起こす可能性があります。 これらの問題については、次のセクションで説明します。

クッキーの食べ過ぎ

ほとんどのドキュメントとは異なり、Web ページは、フォーム、構造、および意味を与えるさまざまな要素の集まりです。 これらの各要素は、独自の Cookie を持つことができます。

.pdf や .docx 形式で表示される通常のドキュメントは、テキストと画像の 1 つの「組み合わせ」のように見えるかもしれませんが、Web ページは多くの個別の小さなパーツで構成されています。

HTML、CSS、および JavaScript は、ほとんどの Web サイトの主要コンポーネントです。
HTML、CSS、および JavaScript は、ほとんどの Web サイトの主要コンポーネントです。

たとえば、Web ページをリクエストする場合、実際には、HTML (構造)、CSS (スタイル/フォーマット)、JavaScript (対話性)、画像などのメディアなどの個別のページ コンポーネントをリクエストしています。 そのため、ブラウザーが Web ページを受信すると、実際にはこれらのコンポーネントを受信して​​再結合し、完全なページを画面に表示します。

Web サーバーも Cookie を送信している場合、このプロセス中にすべての要素とともに Cookie を自動的に送信することがあります。 これは、数枚の画像しかない単純な Web ページではあまり意味がないかもしれませんが、Web ページに数十または数百の異なるコンポーネントがあり、それぞれに Cookie を送信している場合、すぐに圧倒される可能性があります。

実生活で Cookie を食べすぎるのと同じように、HTTP Cookie の送受信が多すぎると、パフォーマンスが低下します。 余分なデータを送信すると余分な時間とリソースが必要になるため、すべての要素と一緒に Cookie を送信すると、膨大な量のネットワーク リソースが簡単に消費される可能性があります。

ドメイン ダイエット: Cookie を使わない

ありがたいことに、あまりにも多くの Cookie を送信するための解決策は、実際のアナロジーを使用しています。パフォーマンスを向上させるには、食べる (送信する) クッキーの数を減らすだけです。

しかし、どの Cookie をあきらめるべきでしょうか? ほとんどの場合、ページ上の静的要素から Cookie を削除することをお勧めします。

静的要素とは、静的画像や CSS ファイルなどの静的ファイルなど、ユーザーの動作によって変更されることが予想されない要素です。 その結果、Cookie を添付する必要がないため、Cookie を削除することは、ネットワークの負荷を軽減し、パフォーマンスを向上させるための最良の方法の 1 つになります。

もちろん、Cookie の削除は、「Cookies」チェックボックスをオフにするほど簡単ではありません。

代わりに、Web サーバーは Cookie を使用しないドメインを使用して、Cookie を使用しない静的コンテンツを、Cookie を使用するコンテンツとは別に配信します。 通常、Cookie のないドメインは別のドメインです (「 static.kinsta.com 」や「 kinsta.com 」などのサブドメインや FQDN など)。

サブドメインを示す URL の構造
サブドメインを示す URL の構造

ありがたいことに、適切なツールを使用していれば、Cookie を使用しないドメインを使用することはそれほど難しくありません。また、サブドメインを設定することが唯一の方法ではありません。

しかし、本題に入る前に、Cookie を使用しないドメインを使用することの最大のメリットと、これが Web サイト (および予算) に与える影響の大きさについて見ていきましょう。

Cookie を使用しないドメインを使用する理由

余分な Cookie を削除するのは小さなアクションのように聞こえるかもしれませんが、率直に言って、そうです。

ただし、この小さなアクションには、かなり大きな利点がいくつかあります。 必要な Cookie のみを送信することで、ネットワーク トラフィックが軽減され、以下に示すその他の多くの利点が得られます。そのうちのいくつかは、パフォーマンスとはまったく関係ありません.

不要なネットワーク トラフィックを削減

Cookie を使用しないドメインを使用するメリットのほとんどは、不要な Cookie トラフィックによるネットワーク負荷を軽減することにあります。

前に説明したように、ページ要素を訪問者に送信するには、一定量のネットワーク リソースが必要です。 要素自体を超えて、各要素 (または同じ要素の複数の部分) は、Cookie などの他の要素と共に、ルーティング情報を含む応答ヘッダーと共に送信されます。

Cookie は比較的小さなデータ ファイルですが、ページ リクエストごとに大量の Cookie を送信する必要があると、すぐに積み重なってしまいます。 その結果、貧弱な Web ホストが圧倒される (その結果、予算を超える) ため、ユーザーはページが読み込まれるまでより長く待たなければなりません。

ただし、Cookie を使用しないドメインを使用すると、不要な Cookie を送信することによって発生する大量のメッセージをほとんど排除できます。

ウェブサイトのパフォーマンスを向上

ご想像のとおり、Cookie を減らしてネットワーク負荷を軽減すると、読み込み時間と Web サイトのパフォーマンスに大きな影響があります。

すべてのページ クリックは Web サーバーへの個別の要求であるため、ユーザーは基本的なナビゲーション ( [ホーム ページ] > [会社情報] > [ショップ] など) を実行するためだけに、長時間待たされることがあります。 ページ要素と Cookie は最初の読み込み後にキャッシュされて再利用される場合がありますが、ページが変更されたり、ユーザーが Web サイトをさらに深く掘り下げたりすると、依然として問題が発生する可能性があります。

利点 SEO とユーザー エクスペリエンス

不必要なトラフィックを減らして Web サイトのパフォーマンスを向上させることで、Web サイトは検索エンジン最適化 (SEO) や、もちろん顧客とユーザーの経験に関してもメリットを得ることができます。

カスタマー エクスペリエンスが最も明白な利点です。ロード時間が短くなるため、ユーザーは必要なコンテンツにより迅速にアクセスできます。 その結果、彼らはあなたのウェブサイト(およびあなたの製品やサービス)を探索する可能性が高くなり、欲求不満でクリックする可能性が低くなります.

同じ利点が SEO にも当てはまります。 ページの読み込み時間は SEO に直接影響しませんが、直帰率 (ページをクリックした訪問者の割合) は確かに影響します。

買い物客は、ページが読み込まれるまで長く待ちたくない
ページの読み込み速度

Unbounce のレポートによると、読み込みに 4 秒以上待たなければならない場合、荷送人の 4 分の 3 がページを放棄します。

これは、不要な Cookie を削除して読み込み時間が 1 秒だけ改善されたとしても、バウンスが大幅に減少し、その結果、検索ランキングが上昇することを意味します。

ホスティングコストを削減

ネットワーク トラフィックは、最終的には Web ホスティング料金としてお金がかかります。

つまり、必要以上の Cookie を送信している場合は、Web ホスティング料金も多く支払うことになります。 また、Cookie がページのパフォーマンスに影響を与えている場合、被害は 2 倍になります。より多くのトラフィックに料金を支払うことに加えて、読み込み時間が遅いために直帰率が高くなるため、同じリターンを得るにはさらに多くの料金を支払う必要があります。

ありがたいことに、Kinsta のようなマネージド ホスティング サービスは、ページ アクセスを最大限に活用するのに役立ちます。 Kinsta は、WordPress ウェブサイトを最大限に活用するのに役立つ APM ツールやその他の機能を提供しています。

クッキーレスの将来への準備

最後に、現時点では直接的なメリットではないかもしれませんが、Cookie を使用しないコンテンツを提供することで、Cookie を使用しない未来に備えることができます。

GDPR などのプライバシー要件に照らして、Cookie に関する論争が高まっているため、多くの主要な検索エンジンやテクノロジー企業は、Cookie を完全に排除する方法を模索しています。 Cookie はおそらくしばらくの間なくなることはありませんが、最終的にはなくなる可能性が非常に高く、準備が早ければ早いほど移行が容易になります。

Cookie を使用しないドメインの使用方法

前に説明したように、Cookie を使用しないドメインの一般的な考え方は、Cookie を配信せずに静的コンテンツを配信することです。 これを行うには、別の静的ドメインまたはサブドメインを作成するのが最も直接的な方法ですが、CDN といくつかの WordPress のトリックを使用することも可能です。

別の Cookie のないドメインを作成する

この方法では、画像や CSS などの Web サイトの静的コンポーネントをホストするための別のドメインを作成します。

完全に別のドメイン名を登録することもできますが、通常は、既存のドメイン名のサブドメインを作成する方が簡単で費用対効果が高くなります。 Cookie を使用しないドメインのほとんどは、単に静的プレフィックス (「 static.yourdomain.com 」など) をサブドメインとして使用しています。

これは、ドメインの「www」バージョン (「 www.yourdomain.com 」など) が Web サイトのルート ファイルのルート ドメインである場合にのみ機能することに注意してください。

サブドメインを Cookie なしにするには、通常、特別なコードを使用して .htaccess ファイルを直接見つけて編集する必要があります。 ただし、後で説明するように、WordPress サイトを単純に再構成するか、プラグインを使用する方がはるかに簡単です。

Cookie を使用しないサブドメインをどのように構成しても、CSS コンポーネント、画像、テキスト、JavaScript などの静的コンポーネントをアップロードできます。

コンテンツ配信ネットワーク (CDN) を使用する

コンテンツ配信ネットワークまたは CDN を使用することは、Cookie を使用しないドメインを使用するための非常に便利な方法です。

ここでは、個別のサブドメインを作成して構成ファイルを編集する必要はなく、静的コンポーネントの応答ヘッダーから Cookie を無視して削除するように CDN に指示するだけです。 少し複雑に聞こえるかもしれませんが、実際には多くの CDN で単純な機能です。

すべての CDN がこの機能を提供しているわけではないことに注意してください。 そのため、Cookie を無効にできる CDN を既に使用していない限り、通常は Web サイトの構成を変更することをお勧めします。

WordPress サイトを再構成する

WordPress を使用している場合は幸運です。Cookie を使用しないドメインを指定するには、wp-config.php ファイルの数行を更新するだけです。 完全な手順については、次のセクション (Cookie を使用しないドメインを使用するように WordPress を構成する) に進んでください。

WordPress プラグインを使用する

もう 1 つの簡単な WordPress オプションは、WordPress Web サイトの静的バージョンを作成するためのプラグインを使用することです。

これを行うための人気のあるプラグインの 1 つが WP2Static (文字通り「WordPress-to-Static」) です。 プラグインをインストールしたら、WordPress ダッシュボードでプラグインを開き、設定を構成して、Web サイトを静的バージョンにエクスポートします。

WP2Static で WordPress サイトの静的バージョンを作成する
WP2静的

Cookie を使用しないドメインを使用するように WordPress を構成する

前述のように、WordPress は Cookie を使用しないドメインを簡単に実装する方法を提供します。 このプロセスは、いくつかの簡単な手順に要約されます。

  1. 代替サブドメインと関連付けられた DNS の追加
  2. どのドメインが静的アセットを提供するかをWordPressに伝える
  3. この新しいアドレスを反映するように既存の WordPress データベース レコードを更新する

Kinsta のお客様は、MyKinsta ダッシュボードを使用して、これらのタスクの一部を実行できます。 他の多くの WordPress ユーザーは、cPanel で同じことができます。

以下で両方について説明します。

MyKinsta を使用して Cookie のないドメインを設定する

Kinsta のお客様は、サブドメイン (または完全に異なるドメイン) を MyKinsta ダッシュボード内の WordPress インスタンスに関連付けることができます。 多くのお客様は、MyKinsta のツールを使用してこれらのドメインの DNS を構成することもできます。

この例では、 www.example.comですでに稼働しているウェブサイトのために、 static.example.comに Cookie のないドメインを作成します。

ステップ 1. MyKinsta でサブドメインを作成する

ドメイン名 ( *.example.comなど) にワイルドカード オプションを使用して、Kinsta で最初に WordPress サイトを確立した場合、サブドメイン名をサポートするように設定されています。 そうでない場合は、次のように、Cookie を使用しないコンテンツ用の新しいドメインを追加できます。

  • 左側のメニューで [ WordPress サイト] を選択します。
  • WordPress サイトの名前をクリックします。
  • 左側のメニューで [ドメイン]を選択します。
  • [ドメインの追加] ボタンをクリックします。
スクリーンショット: MyKinsta 内に別のドメインを追加する。
MyKinsta内にサブドメインを追加。

次のダイアログで:

ダウンタイムや WordPress の問題に悩まされていませんか? Kinstaは、時間を節約するために設計されたホスティングソリューションです! 私たちの機能をチェックしてください
  • Cookie を使用しないドメインの名前を入力します。
  • [ドメインの追加] ボタンをクリックします。
スクリーンショット: MyKinsta 内で新しいドメイン名を入力しています。
MyKinsta 内で新しいサブドメインを指定します。

次に、新しい静的ドメインには、既存の Web サイトを指す DNS レコードが必要です。 サードパーティ プロバイダーを通じてドメインの DNS を管理する場合は、そのツールを使用してそれを行います。 DNSが当社から提供されている場合、MyKinstaで新しいドメインを次のように構成します:

  • MyKinta ホームページの左側のメニューで [ DNS ] を選択します。
  • [ DNS 管理] ページで、[DNSレコード] ブロックまで下にスクロールし、[ DNS レコードの追加] ボタンをクリックします。

新しいサブドメインを CNAME レコードとして DNS に追加することをお勧めします。これにより、IP アドレスとの関連付けに第 2 レベル ドメイン名だけを使用できるようになります。 以下では、 example.comを指すstaticの CNAME レコードを追加しています。

スクリーンショット: MyKinsta 内で DNS レコードを作成する。
MyKinsta DNS 管理で CNAME レコードを作成します。

ステップ 2. 静的サブドメインで Cookie を無効にする

ここで、WordPress サイトのwp-config.phpファイルを編集して、 wp-contentフォルダー内のアセットが「静的」ドメインから提供され、Cookie が「www」アドレス経由でのみ配信されるようにします。

ほとんどのKinstaのお客様は、FTP/SFTPクライアントを使用してWordPressサイトにログインし、編集のためにwp-config.phpをデスクトップにダウンロードします:

スクリーンショット: SFTP クライアントで wp-config.php をダウンロードしています。
wp-config.php ファイルをデスクトップにダウンロードします。

テキスト エディターを使用して、次の行をwp-config.phpファイルに追加します (例のドメインを独自のものに置き換えます)。

 define("WP_CONTENT_URL", "https://static.example.com/wp-content"); define("COOKIE_DOMAIN", "www.example.com");

ファイルを保存したら、WordPress サイトにアップロードして、以前のバージョンを置き換えます。

ステップ 3. 既存のアセットをサブドメインにリダイレクトする

上記の手順により、ブラウザが「www」アドレスからページやブログ投稿などのコンテンツを読み込むときに Cookie が配布されるようになりますが、メディアのアップロードなどのコンテンツや、テーマ内の JavaScript、CSS、フォントなどのアセットが「静的」に関連付けられます。 」ドメイン。

ただし、あなたの Web サイトには、これらのアセットへのリンクを含むコンテンツが既に「www」アドレスにある場合があります。 WordPressデータベース自体で少し検索して置換するだけで、これをクリーンアップできます.

データベースで作業する前に、必ず WordPress サイトをバックアップしてください。 それが終わったら:

  • MyKinsta ダッシュボードの左側のメニューで [ WordPress サイト] を選択します。
  • WordPress サイトの名前をクリックします。
  • 左側のメニューで [ドメイン]を選択します。
  • [サイト情報]ページで、[データベース アクセス] ブロックまで下にスクロールします。 (必要に応じて、データベースのユーザー名とパスワードの情報をここにコピーできます。)
  • [ phpMyAdmin を開く]リンクをクリックします。
  • WordPress データベースにログインします。
  • [ SQL ] タブをクリックします。
スクリーンショット: phpMyAdmin を使用して WordPress データベースのコンテンツを更新しています。
SQL クエリを実行して、WordPress コンテンツのアセット リンクを更新します。

次のコマンドを実行して、既存の投稿内のすべてのアセット リンクが Cookie のないサブドメインに向けられていることを確認します (ここでも、ドメインを独自のものに置き換えてください)。

 UPDATE wp_posts SET post_content = REPLACE(post_content, 'www.example.com/wp-content/', ' static.example.com/wp-content/')

MyKinsta の助けを借りて、WordPress で Cookie を使用しないドメインを正常に構成できました。 このドメインを使用して、WordPress Cookie を送信したくない静的コンテンツをホストし、その他すべてに通常のドメインを使用します。

cPanel を使用して Cookie のないドメインを設定する

cPanelまたは一般的なcPanelの代替手段の1つを使用して、MyKinstaで上記のことを実行する手順は次のとおりです.

ステップ 1. cPanel でサブドメインを作成する

cPanel のメイン ページの [ドメイン]セクションに移動します。 サブドメインツールで、現在の WordPress サイトのトップレベル ドメインに接続されたサブドメインを作成するだけです。

サブドメインstatic.example.comを作成するためのこれらの設定を以下に示します。

cPanelでサブドメインを作成する
cPanelでサブドメインを作成する

ステップ 2. cPanel でサブドメインを静的として構成する

新しい静的サブドメインの準備ができたら、WordPress で静的コンテンツを提供するようにして、その名前にふさわしいものにします。

これを行うには、WordPress サイトのwp-config.phpファイルを編集します。 このファイルにアクセスする最も簡単な方法は、cPanel のファイル マネージャーツールを使用することです。

File Managerで、Web サイトのpublic_html フォルダーに移動し、 wp-config.php (1) を選択します。 次に、編集オプション (2) を選択して、ファイルを編集します。

cPanel File Manager ツールで wp-config.php ファイルを見つける
wp-config.php ファイルを見つけます

wp-config.phpファイルに、次の行を追加するだけです (ドメインを独自のものに置き換えてください!):

 define("WP_CONTENT_URL", "https://static.example.com/wp-content"); define("COOKIE_DOMAIN", "www.example.com");

変更を保存」をクリックします。

ステップ 3. 既存の投稿をサブドメインにリダイレクトする

最後に、既存の投稿を新しい静的サブドメインにリダイレクトする必要があります。 ただし、後で正しく機能しなくなった場合に備えて、WordPress サイトを必ずバックアップしてください。

cPanel の [データベース] セクションで、 PhpMySQLツールを開きます。 サイトのデータベースを選択してから、その_postsテーブルを選択します。

_postsテーブルのSQLタブをクリックします。 次のコマンドを実行して、投稿 URL が Cookie のないサブドメインに向けられていることを確認します (ここでも、ドメインを独自のものに置き換えてください)。

 UPDATE wp_posts SET post_content = REPLACE(post_content, 'www.example.com/wp-content/', ' static.example.com/wp-content/') 
既存の投稿を新しい静的サブドメインにリダイレクトする
既存の投稿を新しい静的サブドメインにリダイレクトする

以上です! これで、cPanel の助けを借りて、WordPress で Cookie を使用しないドメインを設定できました。 画像、CSS、JavaScript、フォントなどの静的コンテンツには Cookie のないドメインを使用し、サイトのプライマリ ドメインでは Cookie を許可します。

Cookie を使用しないドメインは、ネットワーク トラフィックを軽減するのに役立ちます... などなど。 詳細を読むために読んでください️ クリックしてツイートします

概要

Cookie を使用しないドメインを使用することは、サイトのパフォーマンスを改善し、ホスティング コストを削減し、さらにはカスタマー エクスペリエンスと SEO を強化するための非常に効果的な方法です。

これまで見てきたように、WordPress で Cookie を使用しないドメインを設定すると有益です。 ただし、これらの利点を最大限に活用できるのは、Kinsta のような管理された WordPress ホストだけです。

セット Cookie ヘッダーを削除し、データベースに直接アクセスして投稿を静的サブドメインにリダイレクトするための便利なツールにより、Cookie を使用しないドメインの使用がこれまでになく簡単になりました。 KinstaのAPMツールやその他のパフォーマンス監視機能も、結果の追跡に役立ちます.

詳細については、Kinsta をご自身で確認するには、お問い合わせいただくか、今すぐ無料のデモをスケジュールしてください。