Как произошло? У вас не настроены редиректы, а по умолчанию у хостера могут быть подняты как http, так и https. Бывало у клиентов, проходили. Боты обнаруживают, что по https есть ответ по этому домену и его начинают выдавать как основной.
Что делать: если https работает корректно, то просто сделать редирект, выше уже написали как. Если не корректно, то либо сделать валидный https+redirect, либо https надо ложить, а в ВМТ и везде прописывать, что главное зеркало - http.
В любом случае теперь надо корректную отдачу на https делать и потом редирект, ну, или раз уж такая малина - сразу переводить сайт полностью на https, все равно скоро гугл хочет по этому поводу иметь мнение )
А по моим прикидкам, статьи, написанные для моих проектов - сразу в ТОП-1 должны быть, а чет не срастается )) Наверное Яндекс научился понимать, что в статьях все те же 33 буквы алфавита ))
Had, если хотели пошутить - получилось. Если серьезно - то странный вопрос ) С каких пор "качество" статьи вдруг стало единственным фактором ее ранжирования?
Можно, но не обязательно. Товарищ, который и заварил тему своими ошибочными "знаниями" и в этом моменте связал index,follow с canonical, так же как зачем-то с ним связал и директивы rel/next. Почему и вы их связываете? Какое практическое значение вашей связки? Это РАЗНЫЕ директивы, обрабатываются ботами ОТДЕЛЬНО. Они не обязаны друг быть в какой-либо логической связке.
Почему rel="canonical" с нофоллоу? Да потому что каноникал проставлен движком, а шаблонные движки не имеют даже базового сео, практически любой движок требует допиливания до сео, что ВП требует плагины, что Джумла, что остальные. Много вы знаете движков, которые сразу сео учитывают? Сомневаюсь. Но движки ставят правильные каноникалы. На все страницы. Либо при помощи плагинов, и тоже на все. Это логично же. А вот страницы далеко не все при этом нужны в индексе. Потому на те, что не нужны по мнению Вебмастера - ставится ноиндекс. Потому вполне логично, что пачками ноиндекс+каноникал, но эти директивы РАЗНЫЕ и друг другу не мешают и отношения друг к другу не имеют от слов "никакого, совсем".
Много по каким причинам не берут )
А камменты на это г.. о да, как только будут камменты - сразу возьмут! )
Как я и сказал - может быть зашифровано. 🍻
Сделали всю работу за ТС ))
Оба варианта - верные. Но, в первом случае СЕО-оптимизаторы решили, что страницы пагинации не имеют ценности и сливают их потенциальный вес в страницу категории, главную, первую, которая обычно несет в себе еще и СЕОшный текст. Второй случай - классическая пагинация со всеми страницами в индексе. Технически - оба варианта верные. СЕОшно, на мой взгляд, первый вариант - предпочтительнее.---------- Добавлено 15.12.2016 в 18:28 ----------
Модульность, шаблоны. Проставилось и забыли. Смысл вычищать, если все верно и все равно в ноиндекс. Если разбирать большую часть шаблонных движков - там вообще много чего наверчено абсолютно лишнего. Просто не у всех есть деньги, что бы оплатить создание сайта с нуля и только с тем функционалом, который требуется.
Давайте разбираться )
Если у вас были вопросы, мол зачем там 20 страниц - так и написали бы: "Уважаемый, зачем вам 20 страниц одинаковых категорий и контента?" Но вы завели речь о каноникалах, которые к дублям, причем закрытым от индексации, никакого отношения не имеют. Любой движок, у которого есть ЧПУ имеет прямые и ЧПУ страницы, дубли и много мусора, и если это закрыто от индекса - никакого отношения к позициям и ПС это не имеет, и уж точно не является спамом, лишь техническим не индексируемым нюансом.
Вы, подводя итог вашему сообщению, ссылаетесь на последний абзац мануала от Яши, при этом утверждая, что у ТС - каноническая цепочка. Читаем:
Тут четко указан пример цепочки. И Яша имеет ввиду (перекладываем на адреса ТС), что канонической цепочкой было бы следующее:
/elementy-kolodcev/page/2/ имел бы каноникал /elementy-kolodcev/page/3/
/elementy-kolodcev/page/3/ имел бы каноникал /elementy-kolodcev/page/4/ и тд.
Но, при этом, у ТС все правильно
/elementy-kolodcev/page/2/ имеет каноникал /elementy-kolodcev/page/2/
/elementy-kolodcev/page/3/ имеет каноникал /elementy-kolodcev/page/3/
Следовательно, ваша отсылка в корне ошибочна и не имеет никакого отношения к действительности.
Поехали дальше.
- этот пункт мне даже нечего сказать. Почему-то вы решили, что все технические дубли - спам, выше пояснил уже, почему это не так и что они были, есть и будут везде, где есть ЧПУ. Как раз для Гугла, Яндекса и браузеров директивы верные. Гугл их учтет, браузеры исполнят, Яндекс - проигнорирует как несущественные. В остальном - все в ноиндекс, это технические страницы сайта, закрыты от индексации директивами. Все грамотно, разве что самих страниц зачем-то много. Но к технической части вопроса это отношения не имеет совершенно.
При чем тут канонические цепочки? Читаем по вашей ссылке:
Как я и говорил выше, данные теги больше обрабатывают браузеры, ну и гугл их учитывает, Яндекс их просто проигнорирует, таким образом и не пойдет дальше, а учитывая, что и так все закрыто в noindex - он это все проигнорит и ни о каком спаме речи быть не может.
--
Подведу итог. Из всего вашего первого обращения достаточно было сказать: "У вас много одинаковых страниц, но раз они в ноиндекс, то и фиг с этим. Просто зачем столько?" Однако вы приплетаете ошибочно каноникалы, не разбираясь в том, как они работают, для чего нужны и кто использует Next/Prev директивы (более того, Next/Prev не являются каноникалами в принципе и могут использоваться отдельно, без директивы rel="canonical"), пытаясь оперировать неверными цитатами и отсылками. Обе отсылки, которые вы сделали - ошибочны и неверно трактованы. Вы просто вводите в заблуждение тех, кто еще меньше вашего знает, выдавая неверную информацию.
Это в основном клиентские сайты, я не анализировал их ссылочное, поскольку отношения к переезду никакого не имело. На счет страниц - по несколько тысяч и более.
Тогда только изучать, как и писал выше. Начните с полного анализа кода и БД. Учитывайте, что ссылки могут быть зашифрованы, к примеру в base64 и просто поиск по http не эффективен. Если ничего не будет найдено - снимайте абсолютно все сторонние JS и коды, изучайте время изменения ваших файлов, JS, htaccess.. Если не ошибка Яндекса - то источник будет найден. Либо могли сторонние неожиданно пошалить, либо Яндекс нашел что-то, что раньше пропускал.
Полагаю, что решил. Это было давно и решалось, в его случае, довольно просто.
Ваш случай надо рассматривать отдельно. Смотреть как разделить сайты, можно ли убить клона, как клон был "склонирован". Зеркала, каноникалы, директивы.. да много чего.
