- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Что делать, если ваша email-рассылка попала в спам
10 распространенных причин и решений
Екатерина Ткаченко
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Вряд ли речь о зеркальщике идёт, поскольку постранично яндекс не клеит. Впрочем, мы от темы отходим
Хмм... Тоже верю. :)
Главное чтобы новая CMS умела отдавать 404 код при отсутствии страницы по старому адресу, что не факт. Большинство CMS работают по принципу перехвата ошибки 404 и обработки URL по своим внутренним законам. При этом, как правило, если переданный URL самой CMS считается невалидным, то они выдают некую страницу "Такой страницы у нас нету, еггог 404" в красивой форме (дизайне сайта). Но при этом выдают ли они 200 OK или 404 Not Found - нужно смотреть. Если 200 OK - то яндекс не узнает никогда о том, что старых страниц на сайте больше нет, для него они по прежнему будут существовать. Может потом он как нибудь их склеит, если они все будут одинаковые, но это только предположение.
А вообще, для CMS есть одна засада техническая. Заключается она в том, что заголовок, именуемый "Status-Line" ("HTTP/1.1 200 OK"), который и определяет код ответа, на каких-то серверах вывести руками можно (на IIS5, 5.1, 6 точно можно, на Apache - кое-где удавалось), а на каких-то получается ошибка 500 и хоть убейся веником. А что там за код выдаст Apache если Status-line не прописывать - это будет зависеть от его настроек.
А заголовок "Status: 404", который можно вывести на любом сервере, почему-то работает не аналогичным образом. Сижу вот как раз с ним в RFC2616 разбираюсь, и вообще его там найти не могу.
404 работает быстрее чем 301
И их всех делает disallow :) Личный "рекорд" - 5 часов и сайта нет. А все из-за кривых моих рук. Вернул директиву в нужное состояние, сутки и сайт снова в индексе. Закралось подозрение, что он из выдачи только скрывался, а не удалился. Потому как не очень верится, что за сутки вернулось 400 страниц по стойке "смирно".
Соглашусь с Александром. Тоже подозрение, что 404 быстрее. По 301 запросу робот должен сначала удостовериться, что действительно есть перенос на указанную страницу, а не на какую-либо другую (хитробот?). И вообще это возможно делают разные роботы (зеркальщик-редиректор?). В случае с 404: "на нет и суда нет". Т.е. директива 301 не однозначна, в отличие от 404.
на самом деле 404 работает быстрее чем 301
Кстати мысль хорошая. Зеркальщика можно ждать до 2 недель... Что до 404 - система реагирует реально оперативно...
И их всех делает disallow.
Не вопрос, быстрее. Я недавно писал, что была необходимость переиндексить по новой несколько десятков сайтов. В 2 апдейта удалились, еще в 2 обратно в индекс залезли. Но, впрочем это уже совсем далеко от темы. :)