вебдев

Марафон: 100 бурж доров

от

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

Лирическое отступление — опять же, слушая доклады и восстанавливая старые истории, начал приходить к выводу — что вся соль в масштабировании. Создать 100 мелких проектов, каждый из которых в среднем что-то приносит, и получить профит — куда эффективней, чем создать ручками один проект и надеятся. И вся соль именно в автоматизации, делегирование, выстраивании процессов и т.д., и ниша тут вообще побоку. И очень многие топчики занимались именно этим — создавали сотнями статейники, покупали сотнями сайты, делали сотни-тысячи доров, и т.д — и уже потом переходили к крупным проектам. Тот, кто сделал 5-10 малостраничников и успокоился — заработали свои 50-100к рублей и все. Тот, кто сделал 300-500 малостраничников, пусть даже в среднем менее доходные — получили куда более существенный профит. И опять, ключевая способность — это делегирование, ибо ручками в одно лицо делать в случае масштабной работы — нереально, и быстро выгораешь (кто пробовал — тот знает). Оно может и не взлететь, разумеется — но если ничего не делать, то оно гарантированно не взлетит. Ну и не обязательно это именно 100 проектов — это может быть просто 10.000 статей например. И не обязательно серые проекты — белые тоже. Конец лирического отступления.

#smartconf2019, Микола, Алексеич

Так вот. Подумал я над всем этим, и решил — надо бы хоть небольшую сеточку сделать, а то несолидно как-то) Рабочий пример есть, через три месяца 100 уников в сутки, через полгода — 1к уников (дальше пока стопорится), доход $1 с килоуника в адсенсе, еще какую-то копеечку думаю с пушей можно будет получить. Емкость ниши — еще внукам хватит. Яндекса с его придирками нет, РКНа нет. Только Google, DMCA и баны в адсенсе =) 10 — несолидно, можно и ручками сделать, 1.000 — слишком много и затратно (одни домены сколько стоят..), а вот 100 в самый раз. Тут с одной стороны и затраты терпимые (не разорят, если все зафакапится), и профит в случае успеха ощутимый.

А что у нас там с рискам?

  1. Блокировка монетизации через адсенс — но остаются пуши, а раз доры — то и всякие попапы-кликандеры накрайняк
  2. Баны от гугла — гарантированно придут (это ж доры), но по факту аналогичные сайты живут годами
  3. Не будет трафа — ну сорян, бывает, вернемся на завод =)
  4. Абузы — DMCA достаточно мягко работает, регистратор-хостинг — абузоустойчивые
  5. Заблокируют core-функционал — пока что предпосылок нет, и есть альтернативы с более низким качеством

Но есть разумеется и подводные камни, иначе этим бы занимался каждый, не правда ли =) В отличие от малостраничников, которые делаются копирайтерами и с текстовым контентом, и дорами, которые генерятся на автомате доргенами — здесь все несколько сложнее. На первые доры у меня ушло недели эдак две на то, чтобы все отладить и сгенерить сайты. И если по затратам каждый дор будет стоить несколько часов работы программиста — то он никогда не окупится.

Решение — раздробление задач и написание ПО, которое позволит просто толковому человеку (не программисту) создавать подобные сайты, а уж бекенд будет всю тяжелую работу делать. Ну и выкладывать сайт — тоже любой вебмастер справится по чек-листу. Опять же, написание такого ПО для создания 10 сайтов — нерентабельно. Для 100 сайтов — было бы нерентабельно, если бы я делегировал кодинг (а может и нет, но это однозначно затянет сроки, а этого бы не хотелось). Но оправданно, если я сам под себя напишу, отлажу, сгенерю первые 10 сайтов, пропишу все инструкции — и дальше уже просто подкидывать людей в систему, чтобы они делали что 30 сайтов в месяц, что 30 сайтов в день.

Сначала я прикинул, что стоимость сайта обойдется примерно в $100, плюс домен, и такую оборотку я не вывезу, надо будет искать инвестора/кредиты, и прочие сложности (оно конечно интересно всем этим заниматься, но это отдаляет от результата). Но потом подумал, что каждая дополнительная неделя кодинга будет уменьшать данную сумму вдвое, упрощая процесс (совсем его автоматизировать можно, но тогда качество сайтов существенно упадет). По ходу работ конечно видно будет, но мне кажется будет вполне реально уменьшить затраты до $30 на сайт вместе с доменом, что позволяет делать их на свои с достаточной скоростью. Тут в плюс еще и то, что достаточно много кода я уже сам написал, и мне проще будет разобраться.

Serega Kraev, Михаил Шакин

Итого — месяц кодинга, месяц отладки и создания 10 доров самому с написанием инструкций, 3 месяца по 30 доров в месяц, и месяц на всякий случай. К сентябрю сеточка должна быть закончена, а так же будет видно, начали ли первые сайты давать первый траф — и надо либо останавливать конвейер, или дальше пилить/увеличивать обороты.

Расчеты профита простые — через полгода 1к уников на сайте, с монетизацией $1 с килоуника, 100 сайтов * 1к * 1$ = $100/день. Если мои влажные фантазии не оправдаются и на всю катушку сработает один из рисков — то я потеряю месяц на кодинг, и около $3.000 — то есть ниочем, я на кодеропроектах и неудачных покупках сайтов просрал гораздо больше. При этом ROI будет 100% в месяц (три раза ха) — то есть даже если я в 10 раз переоцениваю эффективность, все равно это будет выгодно. Зато научусь делегировать подобные задачи, управляться с сотней сайтов (сейчас у меня их всего 30 — и я только сейчас узнал с доклада Шакина, что есть сервисы для управления WP-сайтами с одного дашборда), какие тут возникают проблемы, как их можно решать, какой продукт можно для этого запилить и т.д. Если оправдаются — то получаем хороший буст по заработку, раскочегариваем конвейер на 1.000 сайтов, начинаем приторговывать сайтами на телдери, продаем софт, пилим инфокурс, отращиваем ЧСВ, рассказываем на серьезных щщах про успешный успех — ну то есть все как всегда =)

Тут можно было бы написать чуть подробней, что за ниша и какие тонкости — но нафига?) Я же не продаю все это кому-то и не завлекаю в нишу, её и так уже пара человек пылесосят и продают обучение с софтом. Отчетики как всегда в итогах месяца, кому интересно — можете до августа 2018-го промотать, когда я начал ими заниматься.

Адсенс. Увеличиваем доход

от

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

1. Трафик

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

2. Конкуренты

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

Анализируйте лоты с Телдери, если у вас проф.статус и рейтинг 30+ — большая часть урлов открыта. Иногда продавцы присылают и срез по блокам, но это в основном уже покупателям. Очень много инсайтов по реально доходным вещам я узнал именно с лотов на телдери (которые при этом иногда даже не доходили до продажи), поэтому дважды подумайте, прежде чем продавать хороший сайт)) По тематикам сайтов — аналогично.

3. Сплиттесты

Базовый инструмент. Как узнать, какой блок прибыльней? Показывайте половине аудитории один блок, половине — другой. Да, одновременно — ошибкой будет неделю показывать один вариант и неделю другой. Если разница между вариантам существенна — то можно быстро заканчивать тест (но набрать минимум 10к показов), но чаще всего разница недостаточно существенная, и требуется более продолжительное тестирование. Иногда разница в платформах — на мобилках больше дохода приносит один блок, на десктопах — другой.

Как проводить сплиттесты? Можно ручками php-кодом, можно плагинами, можно сервисами типа RealBig — как удобней.

Сплиттест уже блоков не помогает? Тестируйте целиком лейауты, то есть все блоки на сайте.

4. Настройка аккаунта

После всего вышеперечисленного можно попробовать немного выжать из настроек. К примеру, включить/выключить деликатные категории, отключить категории, у которых много показов но мало дохода, менять цветовые гаммы у объявлений (делая их более контрастными, или наоборот, неотличимыми от сайта). Все это можно делать с помощью раздела экспериментов в адсенсе. Эффективность как правило не очень высокая (+5-10%), хотя иногда бывают хорошие продвижки.

Сюда же относится блокирование объявлений, но я в это не верю — невозможно заблокировать весь спам, разве что каждый день сидеть и чистить. А вот блокировка по урлам рекламодателей — уже интересней, но тут слишком много тонкостей)

5. Живой опыт

Не забывайте заходить на свой сайт — и с компьютера, и с телефона (обязательно!). Как выглядят рекламные блоки, не заезжают ли за экран, что там рекламируется, правильные ли отступы? Возможно, что адаптивный блок ограничен по размеру, и поэтому не может подгрузить самые доходные размеры блоков — значит нужно захардкодить через css больший размер. Может есть места на сайте, куда блок так и просится, но его там нет? Или наоборот, на сайте так много рекламы, что внимание пользователя распыляется.

6. Ограничения

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

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

————

Оптимизация никогда не останавливается. Сегодня наибольший доход приносят одни блоки, через год — другие. Рекламодатели постоянно подстраиваются под свою аудиторию, и гугл в этом помогает. Большая часть разных опытов и тестов оказывается неудачной, либо не играющей большой роли. Но даже в этом случае лучше прибавлять по 5% RPM каждый месяц, чем стоять на месте или падать. Хотя для неокорых сайтов я забиваю на всё это, и не меняю блоки годами =)

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

Иногда бывает, что всего лишь маленький нюанс в размещении блоков приводит к удвоению RPM или увеличению CTR до 20%:

adsense_ctr2

Но именно поэтому важно иметь достаточно трафика — какой профит от работы по увеличению дохода сайт с 10$ в месяц? Дополнительные 10$, horray! Гораздо интересней вдвое увеличить доход от сайта, который уже приносит $300. Чем больше трафика на сайте, тем больше дохода принесут даже небольшое увеличение RPM на 5-10%.

Всем больших доходов!)

PS. Если у вас сайт с 3000+ уников в сутки, и вы готовы предоставить полный доступ (статы, адсенс, шаблон сайта) — могу поработать над увеличением его дохода. Работаю не со всеми сайтами (не со статейниками точно), стоимость работ — двухмесячная дельта.

Оценка рисков для сайтов. Посещаемость

от

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

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

Сразу отмечу, что курсы по управлению рисками в бизнесе не проходил, со страховщиками плотно не общался, все ниже написанное — лишь моё личное мнение и наблюдения.

«Глупость — это делать одно и то же раз за разом, ожидая разного результата» (с)

В контексте оценки рисков все состоит с точности до наоборот — чем чаще и дольше мы наблюдаем явление, тем большая у него вероятность снова повториться. Какова вероятность того, что завтра взойдет солнце? (с точки зрения наблюдателя на планете) Она не равна единице, но и учитывать данные риски при планирование выходных — не очень умная затея. Зато с погодой — все наоборот, тут точность прогнозов колеблется очень сильно.

Вернемся к сайтам. Чем дольше существует сайт — тем с большей вероятностью он продолжит существовать и иметь тот же трафик. Вы когда-нибудь видели говносайт, который приносит существенно много трафика (тысячи уников в день), и при этом живет достаточно долго (больше 3-х лет)? Такое происходит достаточно редко, так как кроме алгоритмов ПС учитывают и поведенческие факторы, и ручных асессоров, хотя какое-то время такие сайт живут. Таким образом сайт, которому 5 лет, и который дает условные 3000 уников в день — скорее всего еще несколько лет продолжит их давать (только если это не какой-то событийный трафик, или сайт приносит трафик только при активной работе).

Инерция тут чудовищна. Сайты могут постепенно угасать годами и десятилетиями, и в выдаче до сих пор живы сайты 10-летней давности и старше, с какой-то универсальной информацией (справочники и учебные данные, не устаревающая информация, полностью раскрытая). Да, конечно, они постепенно теряют аудиторию, конкуренты не спят, но это заведомо долгий процесс. Именно поэтому я предпочту сайты, которые имеет стабильные полторы тысячи уников уже несколько лет, распределенную между гуглом и яндексом, чем сайт, который поднялся до 3000 уников в прошлом месяце с яндекса.

Факт номер один: чем выше возраст сайта, тем меньше рисков, что он внезапно утратит трафик

Пройдусь по своим сайтам, по падению посещаемости:

10 лет — 5 — 3 — 5 — 8 — 6 — 9 — 11 — 6 — 9 лет

Средний возраст сайта — 7.2 года (кстати, в этом списке нет блога, он не особо посещаем). Кроме одного достаточно молодого сайта (и недавно появился еще один двухлетний) — все остальные имеют достаточную историю. Разумеется, риски для молодых сайтов выше, я держу это в уме.

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

Подкрепляем реальными цифрами

А как же фильтры, спросите вы? Ну что ж, достаем из широких штанин анализатор трафика, и погнали. Возьмем данные 1.019.620 сайта из liarchive, собранную в июне 2017, и сравним её с показателями июня 2016 (учитывая баден баден). Мы ограничим посещаемость от 100 уников в день, и сравним только сайты, по которым есть данные в обоих месяцах — таковых окажется 81.548 сайтов, достаточно большая выборка. Что мы узнаем, сравнив изменение посещаемости за год?

  • 38% сайтов увеличили свою посещаемость (10% — более чем в два раза)
  • 31% сайтов удержали свою посещаемость в диапазоне 70-100% от годовой давности
  • 17% — в диапазоне 50-70%
  • 11% — в диапазоне 20-50%
  • 2% сайтов упали в пять и более раз (меньше 20%)

Замечу, что это выборка лишь по данным LiveInternet, в базе могут быть неточности и левые сайты, и этот способ не учитывает возраст сайтов — только то, что год назад они набрали как минимум 100 уников в день. И все же согласно ней у среднего сайта 70% вероятность того, что ничего плохого с ним за год не случится — потеря трети посещаемости не является чем-то из ряда вон выходящим, это бизнес. Более того, возможно сайты вырастут, и это наиболее вероятный исход.

17% — это вероятность того, что вы накосячили с сайтом, и за год он растерял треть-половину аудитории, и 11% — больше половины или в три раза. Это, однако, тоже не смертельно, в два раза упал доход, но не пропал.

И лишь 2% — что вы совсем потеряете сайт. Чтобы понять, насколько это много, представьте, что вы купили 50 сайтов, каждый от 100 уников в день, самых разных тематик (в том числе какой-нибудь адалт, которые так же есть в выборке, и варез, и укоз), самых разных типов, и через год вы потеряете ровно один сайт. Станете ли вы беспокоится о таких рисках перед началом работы? Вероятность того, что вы совсем потеряете посещаемость на сайте, в 5 раз меньше вероятности того, что вы увеличите её в два и более раз за год.

Кстати, изначально я сделал такую же выборку по 18 тысячам сайтов январь 2016 — январь 2017 (у меня уже были эти базы, пока новые генерировались), и с выборкой сайтов с более 1000 уников в день. Цифры сходятся до погрешности в 1-2%. Сайтов, которые упали с 1000 уников совсем до нуля (не учитывая ограничение в 100 уников), по новой базе насчиталось аж 14%, но это так же многочисленные дропы, дорвеи, порносайты или просто удаление счетчика. Вряд ли кто-то станет удалять нормальный сайт.

Могут ли сайты хорошо упасть по посещаемости? Да, могут. Особенно новостные (перестают накачивать траф), порно, кино и прочий варез. Например, оцените такие сайты, как moevideo.net, politrussia.com или 1001eda.com. Бывает, что совсем сносит ПС траф — а иногда это просто ошибочные данные, как например у анекдотов.нет — по LI гроб, а не деле просто счетчик не на всех страницах, у майлру нормальные данные. Часто перегиб с монетизацией — когда в ход идет кликандер, вап-подписки или инсталлы.

И раз уж я показал сильно упавшие сайты, почему бы не привести и обратную сторону? Например, oppps.ru, infopedia.su и mysekret.ru. И я молчу про эпик вроде russian7.ru (статы открыты, раскачали за год с 30к уников до 400к уников в день).

Факт номер два: реальный риск полной потери посещаемости сайта очень низкий

Один раз достигнув какого-то уровня и закрепившись, сайт может держаться на нем годами. 86% вероятность, что посещаемость вырастет, либо упадет максимум в два раза за каждый год. Вы куда вероятней сохраните и увеличите посещаемость, чем потеряете её. Что конечно не отменяет частных случаев.

Суммируя:

  • Чем старше сайт, тем лучше (3 года — минимум)
  • Легальные сайты стабильней
  • Нельзя жестить с рекламой
  • Вовремя замечайте тенденции и адаптируйтесь (если ваш сайт неудобно читать с телефона — то вы будете терять эту часть аудитории)
  • Сильный перекос в сторону одной из ПС — больше рисков
  • Наличие закладочного/брендового трафика — ощутимый плюс

Если каждый покупаемый/создаваемый сайт рассматривать с позиции «будет ли он актуален через 3-5 лет?», удастся избежать очень многих ошибок, которые по цифрам кажутся привлекательными, а на деле — шлак, который выйдет из моды через 3 месяца, не успев окупится (как покемоны го).

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

В следующих постах поговорим о том, какие еще риски нависают над сайтами, и про главное оружие — диверсификацию, с помощью которой можно держать баланс между доходностью и этими рисками.

Crowd — маркет постовых/упоминаний в блогах

от

Почему-то благие идеи рекламы в блогосфере рано или поздно рушатся от дисбаланса или переходят в соседнее SEO-звено злоупотреблений) (ну или тихо умирают в безвестности, не решив проблему курицы и яйца =) Мне уже давно хотелось бы иметь под рукой сервис, с помощью которого можно было бы с одной стороны легко и ненапряжно проводить небольшие рекламные компании в блогах, и с другой — помогать новым интересным сервисам/проектам находить аудиторию. И наконец-то у меня дошли руки создать его самому — crowd.topsape.ru Заранее предупреждаю — сервис в глубокой бете, и текущий функционал существует больше для проверки востребованности данной идеи, чем на реальную продуктивную деятельность. Пока что это лишь скромненький помощник, а не реальный инструмент.

В чем суть? Я решил отойти от популярной схемы «нагнать на сервис блоггеров/вебмастеров, и дать рекламодателю выбирать» и работать с точностью до наоборот — собрать на сервисе предложения рекламодателей, а уже сами блоггеры могут выбрать что им приглянулось. В таком подходе есть и свои минусы, но мне он нравится куда больше — в рекламе в первую очередь заинтересован рекламодатель, а блоггеров обычно и так заваливают письмами с запросами на платные посты.

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

Если у вас есть сервис/проект подобной тематики, и вам бы хотелось получить немного внимания от блогов — добро пожаловать) Вам нужно будет заполнить небольшую форму, в которых указать свои условия и контакты. Основной «товар» — это упоминания в блогах, постовые, минимальная цена на которые установлена в 100 рублей, максимальную указываете вы сами. Если мимопроходящий блоггер заинтересуется вашим объявлением — он так же через специальную форму укажет информацию о своем блоге и условиях, а сервис передаст его сообщение вам (и заявки на участия, и ответы блоггеров проходят модерацию). Можете сразу добавить мыло cr***@ma**.ru в фильтры против спама, я пока не знаю, насколько хорошо он будет его проходить.

Что дальше делать с этими заявками — решать вам, в текущем варианте сервис умывает руки, вы сами договариваетесь и контролируете процесс установки ссылок и оплаты. Как я уже говорил — это пока что лишь помощник, а не инструмент, а уж в зависимости от востребованности будем двигаться дальше)

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

Энджой!

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

anime-fun-barakamon

Смотрел я на лайт ридер, и думал — куда же еще можно применить внимание аудитории? И вспомнил старую идею про постовые для трафика, а не для ссылочного) На обмозговывание идеи ушли сутки, еще трое — на разработку (15-20 часов). Впервые начал делать проект с композером (свой микрофреймворк перестал устраивать, с Laravel разбираться не хотелось), подключил парочку упрощающих либ — PHRoute для роутинга, Plates как шаблонизатор, основной код котроллеров + вьюхи почти как раньше (только уже с автоподгрузкой классов). Сразу же сделал нормальную админку (обычно ленюсь), подключил Mailgun для рассылки транзакционных писем, jquery для разруливания ajax-запросов (в админке c data-параметрами. Обычно на чистом JS-е делал и onclick). Bootstrap для верстки всего — уже стандарт)

Изначально хотел делать сразу боевой сервис — с безопасными сделками, биллингом, внутренними сообщениями, платой за размещение объявления на сайте. Но вовремя одумался, и в итоге даже регистрацию отбросил, только «ленивое» запоминание данных (благо в случае чего можно быстро авторизировать пользователей через почту), и весь функционал по минимуму. Будет активность — можно будет дальше работать. Даже на такой маленький проект ушло 65кб кода и верстки, пусть и с дублированием — UI для людей требует кучи доп.проверок и кода, всякая машинерия с ботами и данными куда проще) Логику уведомлений на почту тоже пришлось делать с нуля, для мелкосервисов такой канал удержания приоритетен.

Упрощающих жизнь готовых библиотек много, но их еще надо найти и разобраться — если роутинг и шаблонизатор довольно быстро встали как влитые, то с другими пришлось повозится. CrudKit с большим трудом заработал, но вместо админки оказался совершенно неюзабельным. Очень много возни с генерацией и валидацией форм — в этот раз реализовал на стандартном HTML5 + filter_vars с флагами, но стоит попробовать Respect/Validation или GUMP. После написания понял, что хорошо так прокосячил с шаблонами для писем (нужно их сразу во вьюхи выделять), отказ от использования моделей тоже привел к большому дублированию mysql-PDO выборок. Но все равно неплохо иногда вот так с нуля делать минипроекты)

Ставим SSL + HTTP/2 на сайтах

от

Нет, это не очередной мануал про установку Let’s encrypt сертификата — we need to go deeper)

В этом месяце я перевел на SSL + HTTP/2 три своих сайта, включая StoryFinder и IP-Calculator. Зачем? Потому что он есть у конкурентов, и потому что только так можно включить поддержу HTTP/2. Который в свою очередь увеличивает скорость загрузки сайтов для пользователей. Ну и мне просто нравится видеть зеленый значок рядом со своими сайтами, куда уже не воткнут рекламу провайдеры)

На стороне сервера

Начнем по порядку. Я сторонник платных сертификатов на 3 года, которые у GoGetSSL стоят аж $9,65 за все три года. Это на мой взгляд вполне адекватная цена, и без мороки с трехмесячными бесплатными сертификатами и их ограничениями. Зарегистрироваться, оплатить через вебмани, заполнить в CSR свои данные (и сохранить в отдельном файле .key ключ), подтвердить права на домен файлом, еще раз ввести свои данные — и через пару минут архив с сертификатом уже на почте.

У меня впски работают на nginx + php-fpm, без панели управления, поэтому я ставлю все вручную. В ISPmanager можно их загрузить из веб-интерфейса, в бегете — даже получить в один клик, как у остальных — не знаю. Так что изучаем справку у Comodo и заворачиваем cat-ом сертификат сайта и бандл с корневыми сертифкатами.

Можно так же сразу сгенерировать Diffie-Hellman groups командой:

openssl dhparam -out dhparams.pem 2048

(это займет некоторое время, и нужно для усиления безопасности и прохождения SSL теста)

Теперь уже можно менять конфиг, но немного задержимся, чтобы поставить http2 и не возвращаться. Если у вас свежая система и nginx 1.10+ с —with-http_v2_module (проверяется с помощью команды nginx -V), то ничего делать не нужно. Если же нет — идем на оффсайт nginx, ставим репозитарии, и обновляем (возможно, придется побегать с бубном и удалить purge-м старую версию — забекапьте конфиги).

И затем уже для нужного сайта вносим в начало конфига что-то вроде:

server {
listen 80;
server_name www.storyfinder.ru storyfinder.ru;
return 301 https://storyfinder.ru$request_uri;
}

server {
listen 443 ssl http2;

server_name storyfinder.ru www.storyfinder.ru;

ssl on;
ssl_certificate /etc/nginx/ssl/sf.crt;
ssl_certificate_key /etc/nginx/ssl/sf.key;
ssl_dhparam /etc/nginx/ssl/dhparams.pem;
ssl_prefer_server_ciphers On;
ssl_protocols TLSv1.1 TLSv1.2;
ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PSK;
add_header Strict-Transport-Security max-age=15768000;

ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /etc/nginx/ssl/sf.crt;

Редирект с обычной http версии, работа через http2 (да, она включается так просто), и длинный непонятный список cipher-ов. Можно использовать другой список от weakdh, этот я взял с какой-то статьи на хабре. Дальше уже идет стандартные настройки для работы php.

Перезагружаем nginx, готово! Проверить можно на сайте SSL Labs.

image_1

Можно еще обновиться до PHP 7, это тоже ускорит сайты, но у меня слишком много старых сайтов =)

На стороне сайта

Если бы на этом настройка закончилась… Для того, чтобы сайт нормально работал через HTTPS, все свои скрипты и изображения он должен так же загружать через https. И если счетчики метрики и адсенс уже давно с универсальным урлом, то тот же LiveInternet на старых сайтах нужно будет обновить. Все подгружаемые js и css файлы должны вызываться с относительным адресом, либо протоколонезависимыми ( //site.ru/file.js например). Все ссылки так же нужно сменить на новые. Подгружаемые с других сайтов изображения, если сайт не поддерживает SSL, нужно загрузить к себе. Подгрузку изображений/шрифтов из файлов стилей так же нужно менять, если она жестко прописана. Ошибки Mixed Content проще всего отслеживать через консоль браузера в том же Chrome.

Современные CMS обычно в курсе таких перемен, менять придется только инфу в постах — автозаменой, есть такие плагины (а так же Really Simple SSL например для вордпресса). Но вот устаревшие или самопис — зависит от квалификации их написавшего. У меня все три сайта были на самописе, так что пришлось совсем немного поковыряться в шаблонах.

Еще один побочный эффект — при переходе с вашего сайта на «небезопасный» http сайт — будет затираться реферер, и в статистике не отобразится, откуда был переход («с закладок»). Лечится это довольно просто — нужно добавить блок head следующий код:

<meta name="referrer" content="origin">

Так же сбросятся к примеру счетчики репостов, привязанные к урлу страниц, иногда — плагин дискуса.

На стороне поисковых систем

Ничего. 301-й редирект вполне ясно дает понять, куда переехал сайт. В панелях вебмастера гугла ничего дополнительно не указывал, уже через пару дней урлы в серпе поменялись (в панельке тоже автоматом со временем меняются). В яндексе можно вручную поставить галочку «добавить https» в разделе «переезд сайта» — сам он долго соображает и не меняет в серпе протокол.

На трафике и позициях в первое время никаких изменений нет. Будут ли — большой вопрос, это не ключевой параметр, а лишь дополнительный. Но хуже от HTTPS точно не станет — учитывая, сколько шума наводит гугл. А так же благодаря HTTP/2 все изображения/стили/яваскрипты будут загружаться одновременно в одном соединении, что ускоряет загрузку сайтов (к слову, гугл включил его поддержку для своих сервисов, так же как вконтакте, википедия, твиттер и многие другие. Яндекс пока нет). Быстрее загрузка сайтов — лучше для пользователей, даже если это прирост всего на 10-30%. CSP для фильтрации левой рекламы так же становится не нужен.

Есть ли смысл переносить информационные сайты — а почему бы и нет? Ускорение загрузки лишним не будет. Благодаря SNI на одном IP адресе может быть сколько угодно https-сайтов. Хотя санкций скорее всего тоже не будет, ближайшие несколько лет точно.

PS. Все 8 ссылок в посте через HTTPS… Только у nginx нет явного редиректа, пришлось вручную проверить) Впрочем, большая часть айтишных сайтов, особенно связанная с безопасностью, работает через SSL. Сервисы и в рунете большей частью тоже на него перешли.