- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Зачем быть уникальным в мире, где все можно скопировать
Почему так важна уникальность текста и как она влияет на SEO
Ingate Organic
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Приветствую всех.
Прошу простить за объемный текст, но короче не получается.
Также надеюсь, что не ошибся разделом. :)
Вопрос адресован тем, кто знаком с различными реализациями ЧПУ, использовал их в готовых CMS или занимался разработкой самостоятельно и готов поделиться соображениями.
Интересуют способы учета изменений ЧПУ адресов для поисковиков. Т.е. случай, если адрес поменялся и к следующему заходу робота по старому адресу нужно сообщить ему корректный новый. Естественно с нужными заголовками.
Чтобы быть точнее рассмотрю маленький пример. За одно желающие могут покритиковать мое теперешнее видение реализации ЧПУ. Буду за это признателен.
Например имеем статьи расфасованные по разделам. Разделы имею древовидную структуру.
www.site.ru/stati/obzori/videokatri/
Т.е. в базе имеем таблицу с описанием разделов и пару записей вида:
id | name | friendly_url | parent_id
-------------------------------------------------------
1 | обзоры | obzori/ | 0
2 | видеокарты | obzori/videokarti/ | 1
Предположим в какой-то момент вебмастеру захотелось поменять ЧПУ для раздела "видеокарты" или, что еще нагляднее, переместить его в другой родительский раздел.
Соответственно если наша система не умеет уведомлять поисковые системы о переезде раздела, то мы имеем все основания потерять позиции по части запросов.
Как это избежать?
На данный момент я вижу только вариант с хранением истории изменений в какой-либо дополнительной таблице. Храним каждое изменение ЧПУ, а при заходе по уже не существующему адресу ищем не изменился ли он. Но тут вопрос - как долго хранить историю изменений?
Можно конечно попытаться учитывать приходил ли тот или иной робот по старой ссылке и, соответственно, был ли ему сообщен новый адрес страницы.
На этом, пожалуй, все. Буду рад услышать мнение опытных в этом вопросе людей :)
301 редирект ставьте
ложите по старому адресу страницу с редирректом на новую
301 редирект ставьте
ложите по старому адресу страницу с редирректом на новую
Редирект это понятно :)
Я об этом писал: "Интересуют способы учета изменений ЧПУ адресов для поисковиков. Т.е. случай, если адрес поменялся и к следующему заходу робота по старому адресу нужно сообщить ему корректный новый. Естественно с нужными заголовками."
Интересно реализуют ли подобного рода механизмы и если да, то какова их концепция. С технической точки зрения.
Мне тут пришло в голову, что ЧПУ формируемые от структуры разделов, т.е. отражающие их вложенность, они естественно выглядят, но в изменении этой структуры (переносе разделов) мы зависимы от продвижения. Если закупили ссылок на какой-то раздел, то структуру можем поменять только в ущерб продвижению... :(
Сохранять где-то историю изменений. Если при обращении к странице будет 404 ошибка вылетать, то искать в истории изменений, был ли этот url изменен. Если был, то производим замену в адресе и 301 редиректом перебрасываем на новую страницу. В противном случае возвращаем 404 ошибку.
Если изменений будет немного (до нескольких десятков тысяч), то можно их всех хранить.
Да, похоже придется хранить историю изменений в дополнительной таблице. Меня лишь немного пугает объем хранимых в этой таблице данных. Удручает так же механизм чистки записей.
www.site.ru/stati/obzori/videokatri/
если предположить, что у раздела "обзоры" поменялся ЧПУ, то, при такой схеме, эти изменения сказываются и на вложенных подразделах. Соответственно, чем больше вложенность, чем больше подразделов, тем больше записей в таблице изменений.
www.site.ru/stati/obzori/videokatri/gforce.html
А если и адреса статей хранить по такопу принципу, то и каждая статья попадает под изменения...
На самом деле поднимая эту тему, я пытался уяснить сушествуют ли более простые способы реализации подобного вида ЧПУ, когда адрес отражает реальную вложенность разделов и статей. Вероятно не существуют.
Так или иначе, я решил пойти этим путем. В крайнем случае набью шишек :)
Благодарю за участие. :)