Мы переходим с нашего сайта на WordPress на облачную платформу электронной коммерции, которая будет использовать наш основной домен благодаря высокому рейтингу SEO.
Я хочу перенести наши публикации на Discourse и запустить их под тем же доменом. Это возможно?
Для ясности: http://ultraluz.com.br/ будет работать на внешнем сервере, которым я не могу управлять или к которому не имею доступа, поэтому, полагаю, я не смогу использовать хитрости с nginx или что-то подобное. У меня есть доступ только к серверу, на котором будет работать Discourse.
Возможно, настроить Cloudflare перед обоими сайтами с правилом для маршрутизации трафика на Discourse для подпапки. Мне неизвестно ни об одном таком случае. Вам, скорее всего, придётся нанять специалиста или разобраться самостоятельно. Просто следуйте теме здесь о установке в подпапке и любым материалам Cloudflare на эту же тему.
Мне казалось, что мнение о том, что подпапка лучше для SEO, уже устарело. Я бы рекомендовал использовать поддомен, но если у вас есть бюджет, свяжитесь со мной или напишите в Marketplace.
Технически* вы могли бы реализовать подпапку в Cloudflare с помощью правила страницы уровня Enterprise или, возможно, через Workers, но я крайне скептически настроен насчет того, что мы сможем оказать какую-либо помощь в любом из этих случаев.
Поддержка Cloudflare в любой форме, кроме DNS, крайне затруднительна.
И да, сама компания Google опровергла все мифы о SEO-«чудо-средствах», связанных с размещением всего под одним доменом.
Я мог бы привести ещё много ссылок с подтверждающими данными, если бы не был ограничен двумя. И за исключением Cloudflare, который является гигантом и не нуждается в фокусировке на SEO, все сайты на первой странице по этому запросу используют подкаталоги.
Не составит труда найти и другие места, где люди придерживаются того же мнения, поскольку в SEO-сообществе это, кажется, общепринятое мнение.
Но, конечно, если у вас есть ЛЮБЫЕ доказательства того, что поддомен помогает ранжировать корневой домен, просветите интернет
Напрямую от Мэтта Каттса. Ваши «эксперты» по SEO продают вам змеиное масло.
За эти годы некоторые из самых худших и наименее компетентных людей, которых я когда-либо видел в команде, — это «эксперты» по SEO. Они единодушно позорят и опозорят отрасль.
Верно! Гораздо лучше сделать что-то, с чем большинство согласится, что это не поможет в ранжировании сайтов, но, скорее всего, приведёт к неожиданному сбою вашего сайта без ясного способа его исправить.
Я не объяснил достаточно ясно, что это дело для глупцов.
Для ориентира: я бы взял с вас порядка 1000 долларов и не дал бы никаких гарантий, что это будет работать дольше недели после настройки (или, возможно, взял бы 500 долларов без гарантий, что вообще смогу это решить).
Вам также потребуется тарифный план Cloudflare Enterprise.
Если вы заинтересованы, напишите в Marketplace, укажите бюджет, подтвердите готовность оплатить тариф Cloudflare Enterprise и осознайте, что это, скорее всего, невозможно.
Я думаю, что реализация этого завершена на 80%. Я установил Discourse на поддомене как «обычную» установку.
Затем я создал Cloudflare Worker, который проксирует /blog на мой поддомен. Это работает, но Chrome отказывается загружать некоторые элементы из-за политики CSP.
Есть ли у кого-нибудь идеи, как обойти это? Я поделюсь кодом своего Worker, когда всё будет готово на 100%.
Моя идея заключается в том, что после исправления этой проблемы я просто использую robots.txt, чтобы запретить Google индексировать мой поддомен, так что он будет видеть и индексировать только /blog, в то время как я смогу при необходимости свободно обращаться к поддомену.
На самом деле, это никогда не будет работать особенно хорошо при «обычной» установке. Вам действительно стоит следовать процедуре установки в подпапке. Это решит ваши проблемы с CSP и многие другие. Кроме того, я думаю, что вы почти у цели.
Какое значение следует задать для DISCOURSE_HOSTNAME при использовании DISCOURSE_RELATIVE_URL_ROOT? Для меня корневой относительный путь будет blog, верно?
Как это влияет на настройки, связанные с SSL? Вот мой секция env в файле yml:
Настройки Let’s Encrypt и виртуального хоста предназначены для моего nginx-контейнера (jwilder/nginx-proxy), который обрабатывает проксирование и создание SSL на основе этих переменных…
Также у меня было вот это, но, думаю, оно будет полностью заменено кодом выше:
Так не сработало. Думаю, это потому, что воркеру нужен домен для получения данных, а корневой домен находится на другом IP-адресе.
По сути, я говорю воркеру: «когда кто-то заходит на /blog, получай это с rootdomain/blog» — и это, конечно, просто отображает мою текущую страницу ошибки 404 от WordPress.
Думаю, из-за всей этой ситуации с одним доменом, но разными IP-адресами/серверами, для загрузки ресурсов Discourse необходим поддомен. Но уже поздно, и мне нужно спать.
Однако, по-моему, самый простой способ решить эту задачу — просто исправить ошибки CSP с помощью стандартной установки на поддомене.