外部ドメインのサブディレクトリでDiscourseを実行する方法は?

WordPress のウェブサイトから、高い SEO 順位を活かすためドメインそのままで運用するクラウドホスティング型 EC プラットフォームへ移行しています。

投稿を Discourse へ移行したいと考えていますが、同じドメインで運用することは可能でしょうか?

明確に申し上げますと、http://ultraluz.com.br/ は外部サーバーで稼働しており、私が制御またはアクセスできないため、nginx による工夫などはできないと考えています。Discourse を稼働させるサーバーへのアクセスのみ可能です。

私の目標は、http://ultraluz.com.br/iluminacao-para-esportes-como-deixar-as-instalacoes-esportivas-dignas-de-um-atleta-profissional/ のような投稿を Discourse へ移行し、同じパスを維持するか、少なくとも domain/blog/same-url のようにすることです。一方、ルートドメインは Wix 風のプラットフォームに指し示され、ホスティングされています。

Cloudflareを両方のサイトの前面に配置し、サブフォルダへのトラフィックをDiscourseへルーティングするルールを設定することは可能かもしれません。ただし、そのような構成を実行している事例は私の知るところではありません。おそらく、誰かを雇うか、ご自身で解決策を見出す必要があるでしょう。ここではサブフォルダインストールに関するトピックと、Cloudflareの同様の情報に従ってください。

サブフォルダの方がSEOに有利だという考え方はもう時代遅れになった我以为。私の推奨は、サブドメインを使用することですが、予算がある場合は私に連絡するか、Marketplace に投稿してください。

Cloudflareでは、エンタープライズ向けのページルールを使用するか、あるいは Workers を通じて、サブフォルダ化を「技術的には」実現できるかもしれません。ただし、どちらの場合でもサポートを提供できる可能性は極めて低いと考えています。

Cloudflare は、DNS 以外の形態ではサポートが非常に困難です。

また、Google 自身も、すべてのコンテンツを単一のドメインに押し込めるという SEO の「インチキ」については、すでに否定しています。

SEOでは、安全策を講じるに越したことはありません。blog.domain がドメインの SEO を向上させるとは思えませんし、そもそもブログドメインを持つ意味がないでしょう。

このガイドに従おうかと考えています。どちらの ```
assetsPathnames: [“/public/”, “/assets/”]

サブフォルダへのインストールは、はるかに複雑で非常に脆弱です。

ポイントは、同じ FQDN 下で実行することには何のメリットもなく、リスクとコストが大幅に増大するということです。

それはあなたの考えでしょう。しかし、サブドメインがルートドメインのランキング向上に役立つという証拠は全くありません。

さらに、Cloudflare も同じドメイン内ですべてを実行することを推奨しています。

では、なぜ彼らのディスコース・コミュニティがサブドメインにあるのでしょうか?

Cloudflare がドメインに含まれているものは何でも検索順位が高くなるからです。また、彼らのフォーラムは非常に巨大です。

それがあなたの考えなら、通り過ぎてください。ここにはあなたに何もない。他の場所へ行き、あなたと同じ考えを持つ人々が集まる場所へ行ってください。

もし2つのリンクに制限されていなければ、裏付けとなるデータを含むさらに多くのリンクを提示できたはずです。Cloudflareのように巨大でSEOに注力する必要がない場合を除き、この検索結果の1ページ目にあるすべてのウェブサイトはサブディレクトリを使用しています。

これはSEOコミュニティでのコンセンサスとなっているため、同じ考えを持つ他の場所を見つけるのは難しくありません。

しかし、もしサブドメインがルートドメインのランキングを向上させるという証拠が少しでもあるなら、ぜひインターネットに教えてください :slight_smile:

マット・カットス氏直伝。あなたのSEO「専門家」は蛇油を売りつけています。

長年にわたり、私がこれまでチームで見た中で最もひどく、能力が最も低い人々の一部は、その「SEO専門家」たちです。彼らは一様に業界の恥であり、恥ずべき存在です。

その通り!ウェブランキングにはほとんど影響しないと誰もが同意する行為であっても、サイトが予期せずダウンし、明確な修復手段がない状態になるリスクを避ける方がはるかに賢明です。

Cloudflareでこれを実行したことはありますか?

すでに別のトピックで説明した通り、ここでご要望の機能はサポートできません。

Cloudflare のエンタープライズプランを利用するか、カスタムワーカーを作成する必要があります。いずれにせよ、Cloudflare へお問い合わせください。

前述の通り、以前私が回答したもの が、ここで得られる答えのすべてです。

私が十分に明確に伝えなかったのは、これはまさに愚か者の試みだということです。

参考までに申し上げますと、私はこの作業に対して約 1,000 ドルを請求するでしょうが、設定後 1 週間以上機能するという保証はできません。(あるいは、そもそも解決策を見つけられるかどうかもわからない状態で 500 ドルを請求するかもしれません。

また、Cloudflare のエンタープライズプランが必要になります。

もしご関心がおありでしたら、Marketplace に投稿し、予算と、Cloudflare エンタープライズへの支払い意思、そしてこれがおそらく不可能であることを理解していることを明記してください。

この実装は80%完了したと思います。Discourseをサブドメインに「通常」インストールしました。

その後、Cloudflare Workerを作成して /blog をサブドメインにプロキシしました。動作はしますが、CSPポリシーのためChromeが一部のコンテンツを読み込みを拒否しています。

これを回避する方法について、何かアイデアはありますか?100%完成したら、Workerのコードを共有します。

https://ultraluz.com.br/blog にアクセスして、何が起きているか確認できます。

私の考えでは、これを修正した後、robots.txtを使ってGoogleがサブドメインをインデックスしないようにブロックし、/blog だけが表示・インデックスされるようにします。必要であれば、サブドメインには引き続き通常通りアクセスできるようにするためです。

「通常の」インストールでは、この問題は決して完全に解決されません。サブフォルダインストール手順に従うことを強くお勧めします。これにより、CSPの問題だけでなく、多くの他の問題も解決されます。それ以外については、もうほぼ完成に近いと思います。

DISCOURSE_RELATIVE_URL_ROOT を使用する場合、DISCOURSE_HOSTNAME を何に設定すべきですか?私の場合、ルートは /blog になりますよね?

これは SSL に関連する設定にどのような影響を与えますか?これが私の yml の env セクションです。

env:
  LANG: en_US.UTF-8
  DISCOURSE_RELATIVE_URL_ROOT: /forum

  VIRTUAL_HOST: forum.ultraluz.com.br
  VIRTUAL_PORT: 80
  LETSENCRYPT_HOST: forum.ultraluz.com.br
  LETSENCRYPT_EMAIL: redacted@email.com

  DISCOURSE_HOSTNAME: forum.ultraluz.com.br
  DISCOURSE_DEVELOPER_EMAILS: 'redacted@email.com'

  DISCOURSE_SMTP_ADDRESS: smtp.sendgrid.net
  DISCOURSE_SMTP_PORT: 587
  DISCOURSE_SMTP_USER_NAME: apikey
  DISCOURSE_SMTP_PASSWORD: "password"
  DISCOURSE_SMTP_ENABLE_START_TLS: true
  SSL_POLICY: Mozilla-Modern  

letsencrypt と virtual host の設定は、それらの変数に基づいてプロキシ処理と SSL 生成を担う私の nginx docker (jwilder/nginx-proxy) 用のものです。

また、以下のような設定もありましたが、これは完全に上記のコードで置き換えられると考えてよいでしょうか?

run:
  - replace:
      filename: /etc/nginx/conf.d/discourse.conf
      from: "types {"
      to: |
        set_real_ip_from 172.18.0.0/24;
        real_ip_header X-Forwarded-For;
        real_ip_recursive on;
        types {

はい、スラッシュを含めて /blog です。

いいえ、ultraluz.com.br のみです。

LetsEncrypt の部分はそのままにしておいたほうがいいでしょう。

そのようには動作しませんでした。おそらく、ワーカーがコンテンツを取得するためにドメインが必要で、ルートドメインが異なるIPアドレスにあるためだと思います。

つまり、ワーカーに「誰かが /blog にアクセスしたら、rootdomain/blog から取得する」と指示しているわけですが、これでは現在のWordPressの404エラーページが表示されるだけです。

同じドメイン内で複数のIP/サーバーを扱う事情から、Discourseのアセットを読み込むにはサブドメインが必要だと考えています。しかし、もう遅いので寝る必要があります。

おそらく、最も簡単な解決策は、一般的なサブドメインインストールでCSPエラーを修正することだと思います。