Вы определитесь с целью. Вы хотите показывать варианты int для мира и ru для России? Язык то у вас один и тот же, получается? Т.е. у вас должны быть в int те товары, что для Европы там, США, а в rus лежать те, что ориентированы на Россию.
Ну так раскидывайте гео по папкам. Одинаковый товар? Меняйте его описание в зависимости от целей.
Грубо говоря, продавая ковры для русскоязычных пользователей в Америку и в Россию ваша структура должна содержать:
/ru/int - Ковры в Америке, Ковры в Европе, Ковры в Китае
/ru/rus - Ковры в Москве, Ковры в Питере..
И, при этом, должна быть достаточная уникальность, заточенная под региональность. Вот тогда, может быть, гео+язык что-то помогут сделать.
А если у вас и там и там Ковры для всех на русском - так дубли и будут, куда они денутся?---------- Добавлено 01.03.2019 в 15:52 ----------
Да если бы у них проблема в мультиязычности то была. У них по сути 2 отсылки на русский язык, при этом в этих обеих папках одинаковый контент на русском же языке. Как можно это разделить, когда один и тот же язык и одинаковые указания hreflang, по сути.
Я очень сомневаюсь, что lang="ru" и lang="ru-Ru" для Яши является разным. Это нелогично ни по одной причине, поскольку в обоих случаях язык один - русский, а поисковики язык определяют именно как язык, а не географическую составляющую. Это не "En-US" и "En-GB", который определяет локацию, по большому счету это все же британский английский и американский английский. В случае же с "Ru", эти две директивы "Ru"и "ru-RU" на 100% идентичны.
En - Общее указание, что страницы на английском
En-US - американский английский для тех, у кого конкретизирован этот lang в запросе.
En-GB - британский.
А Ru и ru-Ru, в 99,9% вообще всегда отсылаются одновременно.
Как-то так.
Опуская неэтичность, в некотором роде, сайтов, которые изначально имеют проблемы с РКН, а также то, что создавая сайт с нарушениями, вы, в любом случае имеете высочайшие риски, могу обратить внимание на следующий момент:
"Поддержка директивы Host была отключена" - это как ТП Яндекса сказала, такова и на самом деле реальность. А ваш пример за лохматый год учитывает именно директиву Host. Но, она не работает. И, значит, схема уже ничего не даст. Так что и остальные вопросы из того мануала вам не дадут никакого толка.
В текущей ситуации, по факту, нужно делать то, что было сказано изначально, при жалобах на дубль - подавать в суд, доказывать, что это копия сайта и закрывать ее у хостера. Но, учитывая, проблемность контента и остальное - это было невозможно тогда, невозможно будет и сейчас.
Новый сайт, однозначно для ПС более весом, ибо он существует давно, а молодой - был подклеен, ибо он новая пустышка.
Как по мне вариант только такой: расклеивать молодой с тем, что попал в РКН, после чего ждать, что старый сайт будет признан снова основным зеркалом, что уже, кстати не факт, и пробовать еще раз. Может быть были ошибки при переклейке, может неверный порядок переноса был. Поскольку, должны были работать оба сайта БЕЗ 301, и сначала в Яше указать переезд, равно как и в гугле, а уже когда они бы сменили зеркала - ставить 301.
А если начали сразу с 301 - отсюда и результат.
Не совсем понятна организация сайта. По-моему все напутано, что можно и что нельзя.
Если у вас контент для всего мира отделен от контента для Ру, то почему они дублируют друг друга? Это ведь, должен быть или разный контент, или одинаковый контент, но на разных языках и тогда директива hreflang оправдана.
А в вашем случае вы затулили одинаковые страницы дублями, просто в разных папках и сказали, по сути, что там и там язык русский. То есть, фактически, просто создали дубль и ждете, что Яндекс за вас их по-разному раскидает?
Какая разница из какой страны ищет пользователь ваш товар, если он ищет на русском языке? Если у вас завязка от местоположения пользователя, так вам надо вязать все к ГЕО, но никак не к lang. То есть, русскоязычному из Америки нужно показывать usa.domain/ru/item, а русскому из России нужно показывать rus.domain/ru/item с разными данными для разных стран. А у вас все в кучу, получается?
И тогда, уже от языка будут варианты:
usa.domain/ru/item
usa.domain/en/item
rus.domain/ru/item
rus.domain/en/item
с разными гео-ключами и языками. Вот эту структуру - можно будет понять.
Хм, во как. То есть, фактически, уже не просто чат, а прям целый сниппет: что ищете, где ищете. Чую, что скоро у многих такое будет. Все опять будут как новогодние елочки в выдаче. Не хотелось, но чую, что придется все это тоже подключать у себя. Иначе конкурировать будет все сложнее в серпе.
А где они должны регать? От своего имени, юрика? А так зарегали левак на левое имя и работают. Начнутся проблемы, скинут, поменяют на такого же левака с другим доменом и дальше работать. Это черные методы, тут "на себя" никто ничего оформлять не будет.
А в чем сложность то? Делаете оба протокола без принудительного редиректа. В Яндексе подаете на редирект, в гугле нет. Для верности по юзерагенту гугла можно протокол принудительно менять на http.
Вот только, мне кажется, что смысла в этом немного. Риски конечно есть, но https, прежде всего, нужен пользователям. И чтобы операторы мобильных не совали свою рекламу в ваш сайт, это никак не добавляет пользы сайту.
Ну так то:
1. SSL по правильному вешается на выделенный IP. Есть вариант на общем, но он сопряжен с поддержкой, кою не все осуществляют. А, также, на большей части хостингов, точнее на абсолютной массе хостингов подвязать SSL без приобретения выделенного IP невозможно. А новый и свой IP - это как бы +100р/мес. Кому-то существенно.
2. Чтобы поставить SSL, зачастую ничего не понимающему юзеру на сайт - нужно заплатить денежку тому, кто это сделает, и более того, еще правильно настроит переезд и смену протокола.
3. При постановке бесплатного сертификата нужно не забывать его обновлять, или, правильно настроить автообновление, см. п.2.
Еще можно добавить некие риски того, что переход на https будет провальным, многие этого боятся.
Вот, в сумме и выходит, что это не просто так и не бесплатно, при почти любых раскладах.
"не потратил ни копейки" - это уже если есть сервер с выделенным ip + или сам умеешь ставить, или кто-то поставит бесплатно или в рамках УЖЕ оплачиваемого прайса.
Так что, нет, не бесплатно. К чему такие удивления? Если для вас это "легко", то для других реальная жопа )
Когда человеку дают рабочий пример того, что он категорически отвергает - все иные силы убеждения бесполезны. Когда человеку дают круглое, но при этом он твердит, что это квадратное, а круглого не существует в природе и тот кто это круглое создал - шарлатан - дальнейшее обсуждение принципиально бессмысленно. Это как во времена средневековья о физике рассказывать обывателю )
Хотите понять - велкам отдельно, я даже не поленюсь и потрачу лишние полчаса жизни, чтобы на пальцах показать круглое, хотя, рабочий пример я уже приводил, который это самое круглое иллюстрирует на примере, т.е. существует фактически. А остальное - так, троллинг да треп ниочем 🍿
Присоединяюсь, по-моему этих сервисов - только свистни.
Разница только в использовании и некоторых тонкостях.
В таком варианте проверки тошнотности: http://okej.ru/services/morphology , к примеру, можно определить вхождения с учетом морфологической составляющей и весовой части. В определенных условиях полезно, когда слова считаются не каждое отдельно, а словоформами.
Там же можно и тавтологию посмотреть http://okej.ru/services/tautology , тоже, порой, полезно, но, это скорее для проверки читабельности текста.
Так проблема с местом никак не соотносится с вопросом о смене профиля или техники бэкапа, она соотносится лишь с решением по железу, которое требует увеличения места на дисках, а раз это невозможно в текущей конфигурации - придется менять конфигурацию сервера.
Либо пересматривать архитектуру проекта, т.е. если у вас не помещается все на одном сервере - придется делать разнесение по разным серверам и уже каждый, опять же, бэкапить. Локально за счет RAID, удаленно - тут на выбор: удаленный сервак, облако или что еще, в зависимости от уровня требуемого быстродействия и безопасности данных.
Если же рабочий сервер не требует постоянного доступа к архивной объемной информации, то сервер держать как есть, с RAID, а инфу, если это просто накопительный бэкап, который требуется хранить какое-то количество времени - копировать на разные сервера, один опять же локально, второй удаленно. Тут даже и RAID не особо нужен будет, ибо у вас всегда будет 2 копии. А дальше от важности инфы, так то и на каждой точке бэкапа по raid можно организовать.
По-моему вопрос изначально был не совсем верно поставлен. При чем тут новое или волшебное? )---------- Добавлено 25.02.2019 в 18:22 ----------
Грубо говоря, раз невозможно на нем увеличить место, то добавляйте +1 еще такой же сервер и храните бэкап на двух таких серверах, разнося данные в соответствии с требованиями. Что-то оставляете на первом, освободив место от того, что перенесете на второй сервер.
Ну и Disaster придется увеличивать до x2. Если он у вас есть вообще. Как показала практика в свое время с украинским хостером, когда выгорел ДЦ, включая локальные копии - disaster очень даже нужная штука.
