2) Сделать отдельные страницы под каждый крупный город. Написать уникальные SEO-тексты и уникальные мета-теги под каждый город. Загвоздка в том, что сможет ли копирайтер написать 10 текстов про Зип-пакеты?
Подскажите, как будет правильно сделать. Я в тупике.
Определённо вариант 2.
Спамить подряд топонимами на странице не нужно, куда больше рабочего простора на отдельных страницах, которые желательно сделать папками.
10 одинаковых текстов не должно быть проблема для хорошего копирайтера/рерайтера. Впрочем, по мне так и для SEO-шника тоже не должно быть проблемой.
CHATGPT (или разные сервисы по рерайтингу) тут в помощь.
Задача в целом непростая (если задача сделать качественный текст), но вполне по силам.
Кстати, если иконки универсальные их же можно воссоздать?
По-моему, в сети уже есть некоторый коллективный опыт в решении этой проблемы, посмотрите, можете быть просто создадите нужные файлы и положите на место?
В конкретно вашем случае - не причем, у вас проблема просто с тремя файлами, но если проблема массовая и в ссылочной навигации появляются 404 ошибки (причин может быть масса - удалили страницу, удалили целиком категорию и т.д.), то обрываются ссылочные связи и веса не передаются, а робот будет продолжать ходить по этим страницам, ожидая возобновление работы страницы.
Кроме этого пользователи могут ходить по ссылкам ведущим на 404 результат, о проблеме отказов я уже сказал выше.
В твоей буйной фантазии накапливаются тысячи 404-х ошибок.
Если нет реальной практики, открой хотя бы сторонние кейсы и посмотри как люди работают с массовыми 404 ошибками.
Если лень и снова есть желание поерундить, то хотя бы представь, что по ссылкам ещё могут ходить пользовали и пользователи вместо необходимой информации могут получать 404 ответы. Это отказы, а отказы напрямую влияют на поисковое ранжирование.
TC не мучайтесь сомнениями, найдите ту часть кода, где есть ссылки на эти файлы и удалите ссылки. Этого достаточно.
Правильно, пускай захламляется.
Поисковые роботы вместо индексации новых документов будут ходить по сохранившимся ссылкам, ведущим в 404 - нормально.
Если ссылки остаются, ничего ПС не забудет, будет продолжать долбиться.
Про поисковую квоту мы при этом не думаем, про распределение весов тоже - пусть себе накапливаются и в статистике глаз радуют!
Молодец 👍
Напрямую, если на сайте накапливается много ошибок и 404-ых результатов, сайт может быть понижен в результатах поиска.
Заметил в логах много обращений к:
/apple-touch-icon.png
/apple-touch-icon-120x120-precomposed.png
/apple-touch-icon-120x120.png
Из-за трёх файлов понижения не будет, не волнуйтесь, но ошибки надо исправлять.
Если в коде есть ссылки на эти файлы, их необходимо убрать.
И в целом тенденция к исправлению найденных ошибок для активно развивающего сайта должна быть однозначная.
Макс, дебаты закончены, остались вялые попытки троллинга с тем, чтобы спровоцировать на ещё одну волну препирательств и эмоциональных возлияний.
Там где заканчивается аргументация, начинается пустые упрёки и банальное человеческое упрямство.
Но я не психотерапевт, чтобы успокаивать и не аниматор, чтобы продолжать развлекать, поэтому для меня тема закрыта.
Зрячий - увидит, соображающий - разберется.
Открывая ссылку вы загружаете новую страницу? Если да, то ПС зафиксирует переход на новую страницу в рамках одной сессии.
Если вы просто кликнули на ссылку нового документа, при этом быстро переключились назад, то новый документ зафиксироваться с нулевым временем, а может и вообще не засчитаться.
В общем и целом target _blank служит для того, чтобы в потом по необходимости переключаться по вкладкам и переходить с одной страницы на другую.
Если вы возвращаетесь к страницу, но не взаимодействуете с ней, то полезные действия не фиксируются, а значит просто там впустую их открывать и перескакивать туда сюда без дела нет никакой резонности.
target="_blank" - это свойство ссылки тега A. Само по себе оно никак не влияет на поисковые анализаторы, как не влияют свойства html разметки.
Глубина просмотра, кол-во станиц за сессию - всё это относится к пользовательским действиям.
Стартовое действие - это хит (переход), тут ПС все равно, произошёл он с target="_blank" или без оного. Важны последующие пользовательские действия.
Во многом верно, но есть нюансы. Смотрите, в Главное меню могут быть вынесены не все ссылки на разделы и их ветви. Следовательно, Главное меню может отличаться от итоговой структуры сайта. Более того, в меню может не быть ссылок на отдельные пользовательские и служебные разделы, но если ссылки доступны (для обхода и индексации), то они будут определены, проиндексированы и включены в итоговое рабочее древо.
Вот наглядное док-во на живом проекте,
Раздел upload не является элементом Главного меню, но такой раздел в служебной части сайта есть, он имеет вложения и соответственно включён в итоговое структурное древо.
Отсюда вывод. ПС определяют структуру сайта по всем доступным навигационным элементам, а не только по ссылкам доступным в меню.
Больше или меньше - это уже частности. Здесь даже правильнее сказать - Быстрые ссылки зачастую больше определяются элементами Главного меню (вот это важное дополнение).
Древо URL указано в том контексте, что я указываю на древовидное представление итоговой структуры, которое видит ПС (в разделе Структура сайта), но структуру также можно выразить и плоско с указанием вложенности (как я подробно изложил в посте выше). Это уже вопрос представления. Само древо нужно только людям для визуального представления вложенностей, а ПС оно не нужно, оно оперирует сущностями, вам как программисту это я думаю понятно.
Однако уровни древа определяются и формируются по URL вложенности. Если все ссылки находятся на 2-ом уровне вложенности, то древа не будет, потому что само URL древо линейное, например,
site.ru/page1
site.ru/page2
site.ru/page3
...
Это плоское древо или более логично сказать, что здесь нет древа - все страницы на одном уровне (это уже вариант личных интерпретаций, хотя даже и в этом случае можно сделать визуальное представление в виде простого древа с 2-я уровнями).
Есть ещё одна рабочая аналогия, которую SEO-шники и некоторые вебмастера хорошо знают - это парсинг страниц сайта через Screaming Frog. Программа точно также по URL вложенностям формирует рабочее древо и демонстрирует пользователю древовидное представление структуры сайта. Зачем? А для наглядности, чтобы видеть какой рабочие элементы в какие вложены, какой объём родительских элементов и какой состав страниц внутри получившихся разделов.
Программа Screaming Frog не анализирует отдельно Главное меню, она анализирует всю доступную для него ссылочную массу. Аналогично, но только сложнее работает и ПС.
Владимир прав в следующем - как реализуешь эту вложенность, согласно своему представлению структуры сайта, так поисковик проиндексирует и соберет структуру в древо. Но с этой данностью никто не спорит, это очевидные вещи. Главное здесь не наплодить лишних элементов во вложенностях, учитывая SEO нюансы, которые довольно обстоятельно я выше объяснил.
Надеюсь теперь всё понятно, вопрос исчерпан.
