- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
В 2023 году Google заблокировал более 170 млн фальшивых отзывов на Картах
Это на 45% больше, чем в 2022 году
Оксана Мамчуева
Переиграть и победить: как анализировать конкурентов для продвижения сайта
С помощью Ahrefs
Александр Шестаков
Чуть выше предложение было блокировать объявления сразу с учётом корневого домена. Наверное человек тоже заметил, как объявления по типу "вам зачислено" стали часто добавляться с кучи поддоменов одного домена, отсюда и озвученное предложение.
Однако текущий алгоритм изредка спасал от блокировки нормальных доменов, которые корневые, на поддоменах которых размещался мусор. Так что вроде озвученное предложение дельное, особенно в свете появления практики размещения объявлений описанным выше способом, но с другой стороны хоть и редко, но может блокировать и нормальные корневые домены. Может получится какое то оптимальное решение выработать...
За несколько лет не припомню ни одного случая, когда мусор размещался на поддоменах действительно нормального корневого домена. Можно пример?
Nicolas Troz
Зачастую это конструкторы сайтов.
wixsite.com
bitrix24.site
и так далее. На них ведь размещаются и нормальные компании, так что рубить с плеча было бы неправильно, одним махом фильтруя всех, снижая тем самым конкуренцию между объявлениями и доход...
Я тут подумал, можно вот что сделать:
Добавить чекбокс "Добавлять в чёрный список корневые URL" и тут же сбоку будет появляться дополнительно блок для ввода исключений, чтобы вручную добавлять те url, которые не должны блокироваться по корню, а как обычно (с поддоменом). А то я вот помню случай, блокирнулся по ошибке "Яндекс Шеф", который ранее на поддомене был chef.yandex.ru и при блокировке по корню заблокировался бы весь Яндекс с сотнями объявлений. Вот от таких случаев в том числе было бы неплохо ввести исключения, если реализовывать блокировку url по корню.
У меня перестал работать скрипт. Пишет, как будто нет новых объявлений: Execution time: 00:04. Checked: 0. Blocked: 0.
UPD. Обновил куки, заработало.
Лезет уже 3 неделю😖, при переходе по ссылке или ошибка 404, или что-то наподобие низкопробного контента, адрес приблизительно https://doub10t.turbo.site/page1983642 турбосайт 🙁
Увеличил время ожидания curl для загрузки списка рекламодателей (можно менять значение в коде в секундах).
А то несколько тысяч не успевало загрузиться и я не видел ничего.
И важное, на мой взгляд, обновление.
Добавлена проверка размера файла cookie для запуска по планировщику.
Если размер файла менее 5000 байт, то временный файл cookie удаляется и берётся файл cookie тот, что используется для запусков вручную из панели управления.
Файл search_bad_ads.php, строка 55. Там указано 5000. Возможно, не у всех этот файл имеет такой размер.
Если у вас этот файл меньше, то настраивайте под свой размер, а то он будет всегда его просто удалять.
У меня было замечено, что "исправный" авторизующий файл cookie весит 6 кб. Если он становится 200 байт или 4 кб, значит Google захотел авторизации и надо файл cookie заменить.
Последнее время стала периодически "слетать авторизация", этой маленькой проверкой проблема решилась.
Надеюсь, и остальным поможет.
https://github.com/sergeich-gs/adsense-bad-ads-blocker/
Если версия была последняя, то можно несколько свежих файлов с github заменить и всё.
Использую скрипт давно, но что-то руки не доходили такой момент спросить. Если он по крону запускается каждый час, то в момент выполнения (у меня после запуска скрипт выполняется ~20 минут) можно вносить изменения в конфигурацию, а именно добавлять ключевые слова для фильтрации и\или белый список?
И второй момент, т.к. скрипт часто по крону запускается, то по логике имеется теоретическая вероятность запуска в момент, когда будет сохраняться конфигурационный файл (по причине внесения в него новых ключевых слов), что по логике приведёт к некорректному считыванию файлов конфигурации, либо даже их порче?