Нет, ваш запрет индексации - это лишь рекомендация.
По своему усмотрению Гугл может и обходить страницу, и в особых случаях даже индексировать. А потом в Консоли вывести уведомление, что проиндексировано несмотря на запрет индексации.
Запрещайте индексацию и на уровне robots.txt, и на уровне документа (в мета) (если страница попадает в поиск несмотря на запрет в robots.txt).
Также есть вариант запрета через http заголовок, инструкция X-Robots-Tag.
Вполне имеет место быть, что дает возможность пользователю перейти на родительский уровень из карточки товара.
Да, вполне.
Если точка входа пользователя была карточка, то вполне резонно в его CJM может быть потребность перейти в категорию, где будут представлены остальные товары.
Также вывод может дополняться другими смежными категориями, если ввиду специфики товара это может быть полезно и востребовано.
Похоже, что перестали. Я раз за разом встречаю примеры аффилированных сайтов. В настоящий момент даже сам участвую в продвижении аффилиат сайта и при всех моих предупреждениях клиент жаждет вкладывать рабочие ресурсы именно в такой сайт, что создает мне доп. ограничения.
Насколько я понимаю, Яндекс отпустил на волю аффилиат фильтр, фактор накрутки, замороженность сервиса внешних ссылок в Вебмастере.
Как говорится, продолжаем вести наблюдение 🧐
В настоящий момент фильтр не работает.
Скорее вам забанят ваш же сайт, потому что бизнес всегда сможет предъявить доказательства своей легитимности.
Адекватность ТП - это отдельная тема. Нередко ТП не будет сильно погружаться в специфику клиента, а иногда у того, кто вам отвечает просто не хватает опыта, чтобы дать вам качественно полезный совет.
Если из ТП идут бестолковые ответы - меняйте хостинг. Пробуйте, экспериментируйте. Пробуйте хотя бы для того, чтобы увидеть разницу в проверяемых значениях - это важный и полезный опыт в понимании кондиций вашего движка.
Дальше, как уже сказал выше, готовы идти глубже - закажите технический программный аудит. Вам протестируют компоненты движка отдельно и укажут, что именно создаёт ненормированную нагрузку, посоветуют заменить/убрать/модернизировать какой-то отдельный компонент, а вот только потом можно применять различные "кэшеры и ускорители", объединяющие скрипты, css, и прочие технологии которые выполняют кэш плагины.
Лечение CMS нередко надо проводить изнутри, а не снаружи 😉
На сайте TTFB (Time To First Byte) — время до получения первого байта равняется 1,9 сек. Раньше всё было нормально. Глобально ничего не менял, пробовал плагины отключать, ничего не даёт.
Как проверить не проблема ли это в хостинге? Хостинг Бегет.
Смотрите. Отклик от сервера >1 секунд для шаред хостинга это довольно распространённое явление.
В принципе, надо хорошо понимать за что вы борeтесь и какая у вас цель. Если вы борeтесь за цифры, то вы занимаетесь перфекционизмом.
Если вы решаете вопрос с позиции - насколько это значимо для ваших пользователей и мешает работе сайта, то вы в первую очередь должны обращать внимание на метрики FCP и FID, вот это то с чем надо работать - это показатели, которые определяют время от начала загрузки до возможности первого пользовательского взаимодействия т.е. момента когда пользователь увидел результат и сайт готов реагировать на взаимодействие.
Когда FCP <1 секунды - это оптимально, это круто. Такие результаты достигают наиболее оптимизированные сайты и реализовать такой результат обычный вебмастер для насыщенного сайта вряд ли может.
Время до 3 секунд - считается обычным, здесь как раз работают многие бесплатные CMS, впрочем и платные тоже.
Время после 3 секунд уже критическим - вот здесь зона в которой уже надо принимать решительные действия.
Так вот. Первый вариант явно не про вас, потому как у вас TTFB >1 секунды, а если по результатам измерений у вас FCP до 3 секунд, то волноваться вам не за что. Таких сайтов большинство и они нередко занимают топовые позиции.
Если вы в 3-ей зоне - надо разбираться и принимать меры.
Далее TTFB зависит не только от физических возможностей сервера, но также и от вашей программной обвязки. На это значение влияет общая скриптовая часть, кол-во запросов к базе банных и т.д. Если вы просто вебмастер, который поставил WP и играется с плагинами, то на ваши возможности управлять этой областью данных весьма ограничены. Вы можете ставить лишь всякие "кэшеры и ускорители", но они тоже работают лишь по своим заданным алгоритмам.
Чтобы проводить оптимизацию более низкого уровня надо залезать в программную архитектуру, тестировать отдельно программные компоненты, по возможности их выключать, если они не нужны (без потери функциональности), менять порядок их загрузки и т.д. Это уже совсем другой уровень компетенции и качественно иной подход.
Хороший специалист, который в этом разбирается и можем помочь это LEOnidUKG
Если вы готовы на этот шаг, напишите Леониду, возможно он согласится вам помочь.
Но если вы не готовы менять уже сложившуюся функциональность, то по части программных кондиций вы ничего глобально не измените, в этом случае ищите более скоростные хостинги (а для этого их всё равно придётся тестировать) и используйте выделенный сервер. Но опять-таки к конкретной производительности вашего ПО, который мы сами собрали на WP вы никуда не уйдете, поэтому конечно не надо рассчитывать на топовые показатели, где вы не готовы вносить программные изменения (а это может быть долго и недёшево).
Вот так 😉
Так их ещё и несколько?
В общем, реализуйте региональность через папки. Оно конечно можно и через поддомены, но для реализации и управления это будет сложнее, а раз фактической местной привязки к региону не будет и вы рассчитываете на автоматическую по контекстному ранжированию, то я бы подобный проект рассматривал в общей структуре через папки.
p.s. Хотя лично я не стал бы тратить время на такой проект.
Вы хотите сделать аналог Авито?
