GGL не заточен для продажи ссылок с трафиком. Нет инструментов для оценки и контроля этого.
Ссылки с трафиком - это контекстная реклама, баннеры и тизеры.
Но непонятна экономика сайта. Доход планируете получаться с сайта? Как?
Рабочий вариант уже был оглашен:
- хостер, при наличии интереса, объявляет публичный конкурс на поиск уязвимостей с указанием правил и вознаграждения;
- заинтерисованные условиями участники соревнуются в справедливой борьбе - находят уязвимости или достают из закромов.
Таким образом повышается защищенность всех сторон. Хостер заплатит только за выявленную уязвимость (соответствующую правилам), участники будут действовать в правовом поле.
1. Трояном украли ftp пароль у вас или исполнителей (на сервере ведется лог ftp авторизаций и операций - если есть доступ, то можно проверить )
2. Шелл на сайте установленный администратором вместе с темой или плагинами
3. Шелл на сайте приобретенный через уязвимости
4. Теоритически соседи по шаред хостингу (спрашивал, хостеры клялись, что каждый работает от своего пользователя и это невозможно)---------- Добавлено 04.02.2014 в 17:15 ----------
Я бы не надеялся на антивирусы. По факту, мне приходили жалобы от хостера на htaccess, а что еще и index.php был инфицирован не было обнаружено.
Нужно понимать, что поиск по base64 и strrev - прошлый день, старые версии закладок.
Последний встреченный экземпляр тело подкачивал из картинки.---------- Добавлено 04.02.2014 в 17:32 ----------
Найти шелл в wp - на 100% решаемая задача, никакой магии там нет.
Но она требует знаний php, немного понимать в wp, внимательности и упорства (примерно 1000-1500 файлов).
Вот облегченные варианты:
1. Сравнить сайт со старым бекапом (заведомо чистым)
2. Сравнить сайт с официальной wp соответствующей версии (чтобы различия были минимальные), только стороннюю тему и плагины так не проверить
Инструмент - Total Commander (сравнение папок, сравнение файлов)
Нужно лечить причину, а не маскировать ее.
На большинстве хостингов не поможет (если права выставленные через ftp доступны для исправления шеллу работающему от имени веб-сервера).
Я считаю, что теги H следует применять только для структурирования основного контента страницы.
Все остальное - меню и блочки являются дополнительной навигацией и вспомогательной информацией, метить это семантически не требуется. Т.е. выделять более важные блочки и менее важные не нужно, они все НЕ важные.
Заголовки неких прочих статей - типичный вспомогательный блок, посетители не за этим приходят на сайт.
Таким образом, если "Заголовок дополнительной статьи" пометить не в H2, а любой другой контейнер и настроить стили, то проблема будет решена.
Про сквозные H1 я не понял. Сквозной блок - это блок с одинаковым содержимым на всех страницах. Но H1 должен содержать заголовок к контенту и должен быть уникальным в пределах сайта, т.е. сквозным не может быть.
Это что, в стандартной теме wordpress 2012 заголовок сайта h1, а название сайта - h2. Естественно, переделал.
А заказчик делиться своими свежими познаниями, типа посоветываться, или требует их удовлетворить?
И почему вы считаете, что требование невыполнимое?
Заливать сайт. Если там была только заглушка, то чего беспокоиться.
В пределах месяца получите ответ. Этот срок разве что-то решат?
Я бы обратил внимание на то, что cms это инструмент. А инструмент должен быть привычный, хорошо изученный. Может где-то тяжелый, в чем-то неудобный, требует ресурсы, но его глюки известны, костыли найдены и за счет привычности быстро дает результат.
Копаться в экзотике, изучать новые грабли часто непродуктивно и стоит только при наличии высокой цели.
Такой инструмент - это свой движок и/или один из популярных (wordpress, joomla, drupal...) с хорошей документацией, комьюнити, шаблонами, наличием фрилансеров.
Поэтому выбирайте то, чем владеете лучше всего и совершенствуйтесь.
Относительно причин выбора cms на файлах скажу, что вы пытаетесь решать не причину, а следствие. Проблема ведь не в cms, а в организации вашей работы. У меня все сайты на mysql и особых сложностей я не заметил.
Кроме того, cms на файлах хороши в простых задачах, для статических сайтов. И будут проигрывать тому же mysql как только потребуется сортировка, фильтрация даных, протоколирование, обновление счетчиков. Вы сужаете класс задач которые сможет решать ваша cms, сужаете список подходящих cms.
Как вариант базы данных можно посмотреть - sqlite3.
Кстати, есть любопытные варианты, вчера читал про опыт человека подключившего wordpress к sqlite. Правки буквально в нескольких местах и имеем нормальную базу в папке с самой cms.
Это был пример возможного негативного фактора. Я пытался донести ТС мысль, что если не знаем как точно реагирует система (яндекс), что стоит придерживаться нейтральных к нам общепринятых стандартов, т.к. этот путь имеет наименьшую вероятность получить пенальти. Потому, что даже соблюдая правила можно стать жертвой несовершенства системы - зеркальщик яндекса тому пример.
Уточню: под ошибками я имел в виду варнинги php.
Почерпнул из интервью Садовского (2013 г):
- Насколько наличие и частота технических ошибок на сайте понижают его при ранжировании?
- Яндекс не понижает сайт в выдаче из-за того, что тот содержит технические ошибки. Они могут приводить к невозможности индексации, к побочным эффектам, которые в конечном счете сказываются на ранжировании, но сам алгоритм никого не «наказывает».
- Для каждой из многих миллиардов страниц мы рассчитываем около 800 факторов ранжирования, описывающих какое-то свойство страницы или сайта.
В свете приведенного фрагмента, мои предположения о явном влиянии ошибок маловероятны.
Тем не менее, редирект всех несуществующих страниц, а не только когда-то проиндексированных, по моему мнению, не является примером для подражания.
