Спрашиваем и отвечаем по Wordpress-12

Всё правильно говорите, с двумя поправками. Якорная страница Вордпресса - та же самая, что и не якорная, что для Гоши, что для Яши, а rel="canonical" указан на странице без якоря, а так как она идентична неякорной, rel="canonical" оказывается и на якорной, потому что - куда бы она делась со своего места?

Если я правильно понял из следующей новости, то во втором квартале 2018 года, Google будет распознавать якорные ссылки, как отдельные страницы.

В статье речь о #!, но я уверен, речь идет об якорных ссылках вообщем.

/ru/news/1029230

Теперь эта ситуация изменилась, и Google будет сканировать и обрабатывать сайты на AJAX, как есть. Это значит, что поисковик будет рендерить #! URL напрямую, и вебмастерам больше не нужно будет предоставлять отображаемую версию страницы.

Эта уверенность на пустом месте. Было бы жуткой несуразностью считать различные представления одной и той же страницы разными страницами.

https://webmasters.googleblog.com/2017/12/rendering-ajax-crawling-pages.html

Оригинал.

Я думаю, что новость упускает этот момент.

По сути #! и # технически оба якорные ссылки.

В новости четко сказано, что бот будет напрямую рендерить содержимое якорных ссылок (# или только #! упущено).

Почему я думаю, что речь идет о якорных ссылках в общем.

Потому что Google работает над развитием Progressive Web Apps.

И тут стоит вопрос, как индексировать всплывающие меню, ленивую подгрузку результатов и списков. В PWA, динамичность на каждом шагу. И очень редко эта динамичность сопровождается изменением URL.

По сути это Ваши личные домыслы. И никто ничего не упускает, это Вы отсебятину добавляете.

Поставил тоже на тестовый сайт - да, действительно. В виджете ссылки с языковым "каталогом". Но все остальные ссылки - нормальные. И это главное.

В принципе, если сильно парит, то можно выводить не родным виджетом, а написать свой небольшой плаг для этого. Или же написать разрабу чтобы исправил. Только сдаётся мне им уже никто не будет заниматься - почти 2 года плаг не обновлялся.

Ещё как не в тему. Для сеошных вопросов на форуме есть куча др разделов.

А сеоересь тут постить не нужно, ortegas, понятно?

По сути каким ты [cens] был, таким же и остался.

А если ты думаешь, что тебя тут забыли - ты глубоко заблуждаешься.

Я думаю, что вы просто злитесь через то, что не можете предоставить такие же качественные ответы, как я.

Хороший пример того, что получит человек, если обратится к вам в ЛС с бюджетом от 50$ (судя по вашей подписи).

Может лучше потратить время на более качественные ответы по теме, а не желчь?

Если находясь на /en/example перейти на /example (ru - по-умолчанию), редирект пойдет на /en/example обратно.

Потому, что плагин записывает последний язык в cookie qtrans_front_language.

И чтобы его перезаписать, нужно сначала открыть /ru/example (который присвоит новые cookie и выполнит 302 редирект на /example).

Но даже если функционал cookie выпилить, плагин все-равно будет пытаться определить предпочитаемый язык через referer.

И если с /en/example перейти по ссылке на /example (ru - по-умолчанию), плагин перебросит все-равно на /en/example (на основе referer - предыдущая страница была на английском).

Это не ошибка плагина, а его дизайн.

Разработчик не планирует исправлять это в последующих обновлениях.

https://qtranslatexteam.wordpress.com/browser-redirection-based-on-language/

Виджет не просто выводит ссылки на /ru, /en.

Он выводит ссылки на языковые версии текущей страницы (/en/example, находясь на /example).

Однако, проблему решили в ЛС.

Возможно кому-то будет полезно решение проблемы.

qTranslate X практически не использует систему хуков, поэтому, решение затрагивает правку исходного кода ядра плагина.

Это означает, что работы нужно вносить после каждого обновления плагина.

qtranslate_core.php

1. Отключаем функционал cookie для фронт-энда.

Это означает, что если пользователь однажды выбрал у вас на сайте англ. версию и перешел с поиска на русскую версию по-умолчанию, он больше не будет переброшен на англоязычную версию.

Функция qtranxf_loadConfig

секция switch($url_mode){

case QTX_URL_PATH:

$q_config['disable_client_cookies'] = false;

установить в true

2. Отключаем восстановление языка по Referer.

Это означает, что если пользователь перешел с /en/example на /example-2, он больше не будет переброшен на /en/example-2, а ему будет показана версию по-умолчанию.

Функция qtranxf_detect_language()

секция if(!qtranxf_external_host($ref_info['host']) ) {

изменить условие if на if(false and !qtranxf_external_host($ref_info['host']) ) {

3. ВСЕГДА сокращаем путь в ссылке для языка по-умолчанию (затрагивает в том числе ссылки в виджете).

Функция qtranxf_convertURL().

В самом верху вставляем $showDefaultLanguage = false;

Вы,, похоже, не дочитали о моей проблеме

Как решить? При первом же обмене ведь дубли товаров будут созданы.

Ну вроде как у товаров артикулы всякие есть, а в настройках плагинов задаётся, что и как обновлять. То есть товары, которых нет ещё, всё равно ведь появятся, и всё равно эта же проблема возникнет.

Это стандартный функционал импортера Woocommerce.

Он умеет обновлять уже существующие записи из CSV.

Подробно об этом расписано в документации.

Дайте знать, если не понимаете английский, я переведу.

https://docs.woocommerce.com/document/product-csv-importer-exporter/#section-5

Импортер использует ID или SKU (артикул) для связки товаров между базой и CSV.

Соответственно, нужно либо:

1. Прописать артикулы (SKU) для товаров на стороне Woocommerce.

2. Задать ID равны ID товаров на сайте в самом CSV.