Известно, что наличие сайта в DMOZ повышает рейтинг в поиске Google, но ход регистрации может длится сильно длительно. В этой статье я объясню, зачем регистрация зачастую занимает непочатый край времени и что нужно действовать, когда заявка на добавление dmoz является причиной задержки.

Но прежде я объясню, что такое DMOZ и отчего стоит поворотить на него внимательность. Произвольный сайт или страничка просматривается вручную перед добавлением в каталог. Регистрация бесплатна. На самом деле мало людей используют DMOZ для поиска в той же мере как Yahoo!, И все-таки его базой разрешено употребить в целях создания собственного каталога сайтов.

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

Оба заурядно имеют пристойный PageRank. В настоящее время, добавив сюда ссылки на тысячах маленьких сайтов, которые загрузили и используют каталог DMOZ, Вы увидите, почему просто очень выгодно для сайта быть внесенным в DMOZ. Простое внесение в DMOZ может вознести значимость Toolbar PageRank от 3 до 4, и более того от 4 до 5. Почему регистрация в DMOZ занимает немало времени? На самом деле у них нет столь модераторов, даже рядом к этому.

Это цифра - общее число модераторов с момента старта проекта. Большинство из них больше не работают. Существенная количество тех, которые ещё являются модераторами, неактивны или кот наплакал проявляют активность. Так что число модераторов, активно рассматривающих и добавляющих сайты, сравнительно негусто. С иной стороны, невпроворот сайтов стоит в очереди на рассмотрение. Некоторые модераторы имеют занятие с маленькими разделами и малым числом заявок, и, сообразно могут совладать крайне стремительно.

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

Представьте как кто-то подает заявку на внесение сайта в категорию, которая является близкой по его содержанию, но сайт на самом деле принадлежит к прочий категории. Что случится? Заявка ожидает в очереди категории, на которую представлена заявка. До времени или поздненько наступает ее очередность, и модератор находит, что сайт принадлежит к другой категории. Тот модератор не может редактировать другую категорию, так что заявка будет передана к другой категории и добавлена в очередь.

Заявка не пойдет за пределами очереди из-за того только, что уже ждала в другой. В конечном счете наступит еще раз ее черед и она будет рассмотрена заново. Это - простая последовательность событий, когда сайт представлен к неправильной категории. На практике, тем не менее, нередко случается по-иному. Если Вы не побеспокоились отыскать правильную категорию для сайта, не буду этого работать и я ".

Так что сайт часто отсылается категории, которая является более близкой, но окончательно не во что бы то ни стало к нужной.

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

Не соблазняйтесь вручить заявку на категорию, которая находиться выше правильной в дереве категорий, потому что что она не будет принята. Поступая так, не возбраняется побудить ненужные задержки. Почему некоторые сайты получают отказ? Политика DMOZ - рассмотррение сайтов, которые имеют уникальное содержание.

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

Некоторое содержание таковой информации приемлемо, но когда она занимает хоть отбавляй места на сайте, то он наверное будет отклонен. Другая причина отказа - из-за заявки. Лично, я нахожу трудным уверовать, что модераторы сделали бы это, но я слышал о таких случаях. Так что читайте и следуйте рекомендациям при заявке сайта. Очерчивание предназначено для того, чтобы вручить людям взять в толк, что может быть найдено на сайте, а не для раскрутки.

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

По материалам http://wm-help.net/articles/print/28.06

Я постарался располагать советы по степени важности, начиная с самого важного. 1. Задавайте ширину страниц в процентах, а не в пикселях. Горизонтальная прокрутка это единственный из самых существенных недостатков любого сайта. 2. Размещайте самую интересную для посетителей информацию в верхней части страницы, так, чтобы она была без прокрутки. Ваша первая проблема - заинтересовать пользователя, потом, вам придётся приложить усилия чтобы удержать его, но если посетители уходят тотчас, то держать будет легко некого.

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

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

Используйте для выделения тучный шрифт, или курсив, прочий кегель и шрифт. 5. Выделяйте разным цветом пройденные и не пройденные ссылки. В особенности это правило актуально для страниц с содержанием для больших архивов. Никто не любит гулять по одной ссылке два раза. 7. Навигационные ссылки в виде картинок должны обладать комментарий с разъяснением, куда попадёт посетитель.

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

9. Логотип сайта постоянно должен быть ссылкой на главную страницу сайта. 10. Посетитель должен несложно и стремительно выискивать ссылку на архив информации на сайте. Может быть, он ищет какую то конкретную статью 11. Если вы предлагаете скачать какой-либо файл, то обязательно укажите его габарит, не заставляйтё посетителей лишаться личное момент. 12.

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

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

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

Совершенно безусловно, что выполнение всех этих советов не гарантирует успеха на 100%, уж очень страсть сколько других критериев влияет на популярность ресурса, но в любом случае ваши посетители оценят ваш работа. Успехов вам в этом нелёгком деле!

По материалам http://wm-help.net/articles/print/28.06

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

Предлагаем следующий алгоритм действий: Каждый день в 5 утра, cron на сервере www запускает скрипт backup.pl, тот, что выполняет следующий строй действий: Создает дамп базы и архив каталога htdocs. Копирует дамп и архив на backup-сервер. Запускает на backup-сервере скрипт store backup.pl, который выполняет следующие дествия: Удаляет каталог htdocs и пересоздает пустую базу данных. Разархивирует архив файлов и восстанавливает базу данных из дампа. Добавляет информацию в. Делает иные действия, требуемые для работоспособности перенесенного сайта.

Создает каталог с именем, совпадающим с текущей датой и в него переносит новые backup-файлы. В результате живого бэкапа, на резервном сервере неизменно будет работоспособная версия сайта.

Заказчик сможет обследовать, что backup на самом деле существует и работает и это придаст ему хладнокровие и уверенность в качестве услуг. По датам сообщений на сайте будет видно, что резервная копия сделана в эти дни в 5 утра. Образец В качестве примера рассмотрим бэкап сайта webew.ru. На каждом сервере настроен apache, на первом на адрес webew.ru, на втором на адрес backup.webew.ru.

На каждом сервере есть пользователь webew, база данных webew, а корневой каталог сайта - каталог htdocs в домашнем каталоге пользователя webew. Помимо того, для удобства поместим имя и пароль для доступа к базе данных в файл. Start backup. 2... 2 webew backup. Скрипт store backup.pl на сервере backup: ! AuthType Basic AuthName webew AuthUserFile home webew. Файл. Если вы опасаетесь взлома основного сервера, то процедуру разрешено направить: скрипт.

В таком случае злоумышленник, получивший доступ к основному серверу не сможет принять ssh-доступ к резервному. Заключение Живой бэкап позволяет заказчику быть уверенным, что резервная копия в действительности есть. Кроме живого бэкапа, не забывайте беречь копии проектов на локальной машине и на сменных физических носителях. Все права на данную статью принадлежат порталу webew.ru.

Перепечатка в интернет-изданиях разрешается только с указанием автора и прямой ссылки на оригинальную статью. Перепечатка в печатных изданиях допускается только с разрешения редакции. Резервный сервер находится в "теплом" состоянии. Т.е. MySQL и Apache не запущены. При необходимости запускаем Apache и MySQL и получаем рабочую копию сервера. Попутно решается задача, когда бекапить надобно кучу сайтов. Копирование файлов базы при том, что первостепенный сервер работает, с большущий вероятностью приведет к битым таблицам.

Оптимальный вариант: rsync + репликация базы данных, но в этом случае испытать работоспособность сайта-копии будет нельзя, так как это нарушит репликацию. Если бинарики таблиц напрямую копировать будут траблы. Ибо это только усложняет задачу, причем, не совершенно обоснованно. С дампом может быть ряд неприятностей.

Неприятное следствие в том, что когда дамп требуется возродить, у него могут внезапно вскрыться недостатки, которые никого не беспокоили до этого. В настоящее время, пускай я заказчик. Я знаю, что есть дамп. Но позволительно ли его будет воссоздать или нет? Нелегко произнести глядя на дамп, не тестируя его. Предложенный подход автоматизирует тестирование.

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

Предположим, на моем VDS у меня есть план projectname.ru и я решил произвести его резервную копию на backup.projectname.ru на том же VDS. Всё великолепно работает, но в единственный не хороший день на сервере сыпется хард и я теряю как основную версию сайта, так и бекап. Нет смысла живой backup действовать на том же сервере. В частности, рассмотренный в примере сайт webew переносится на backup.webew.ru, размещенный на отдельном георгафически удаленном VDS.

Как отметил paulus, лучше эти скритпы прямо строчить на bash.

По материалам http://webew.ru/articles/1462.webew