Судя по:
забанили по IP.
ТС, бери хостинг на одном IP с gov.ru - там обижать не посмеют.
А лучше - меняй домен и переклеивай сайт. Быстрее и проще, чем отменять решение суда - пока оно действует, сайт будут банить постоянно.
Подключите ajax - он запрещает кроссдоменные запросы.
После загрузки вашей формы в в браузер пользователя - по onLoad на сервер отправляется ajax-запрос. который генерит, например MD5( от текущего времени + IP пользователя).
Этот MD5 записывается в БД на сервере и ему ставится время жизни, допустим 3 часа. Устаревшие вычищать из таблицы по cron. Это не даст нагеренить правильных ответов для работы "левого скрипта".
Форма присылает на сервер файл и скрытое поле с ответом на этот ajax-запрос, поле сверяется с наличием в таблице. Если не совпало - пользователь левый, заново отправлять ему форму ввода файла.
Плюс - реферер проверяйте, браузеры сейчас не дают его подделать.
Нужно учитывать, что биржи ссылок придумывают разные мифытренды в попытках реанимировать свой стагнирующий бизнес и пытаясь оттянуть свой конецколлапс.
Поисковики сильно ограничены в технических возможностях учёта переходов по ссылкам(бары, метрика, свои браузеры).
Зато у них есть отличный инструмент вероятностного учёта таких переходов, с учётом естественности ссылки в контексте страницы.
Делается всё элементарно, и "руками самих пользователей ПС".
Накрутить это "усилителями ссылок"(создавая фактические переходы по ссылкам) не получится, поскольку накручивать пытаются следствие, а не причину.
Там ноги растут из другого места, дело вовсе не в переходах по ссылкам - переходы вторичны, а ПС опираются на первичный фактор, который они контролируют.
Когда у Рамблера был собственный поисковый движок - трафик с Рамблера конвертировался лучше, чем с Яндекса. Это положительно свидетельствует о контингенте пользователей..
jaolav вам совершенно грамотно ответил. А вы - всю жизнь "считали" неправильно.
Сайт-аудитор может считать что угодно - слова, символы, байты. Только к СЕО это отношения никакого не имеет.
if ($IfModifiedSince && $IfModifiedSince >= $LastModified_unix) { header($_SERVER['SERVER_PROTOCOL'] . ' 304 Not Modified'); exit;}
1. Это некорректный код, решение отдавать заголовок "304 Not Modified" или "200 OK" принимается по более сложному условию.
2. Тупо слать LastModified при каждом обращении к серверу - бессмысленно и ничего не даст. Кэширование на стороне клиента работает не так:
Если при обращении к серверу был прислан заголовок If-Modified-Since(с датой локального кэша страница у пользователя/робота ПС), то:
- если страница не изменилась с этой даты - сервер отправляет заголовок "304 Not Modified" НЕ ПРИСЫЛАЯ ТЕКСТ САМОЙ СТРАНИЦЫ!
- если страница изменилась - сервер отправляет LastModified, код "200 OK" и ТЕКСТ САМОЙ СТРАНИЦЫ.
Если при обращении к серверу заголовок If-Modified-Since не прислан - клиент не поддерживает кэширование и LastModified отсылать ему бессмысленно, ему всегда оправляется страница сайта.
Хотя по RFC для HTTP1.1 Серверы HTTP/1.1 должны посылать поле Last-Modified всякий раз, когда это возможно.
Я проверила сей сервис "изнутри" - он работает почти корректно:
- сначала посылает запрос для определения даты изменения документа
- потом второй запрос: IfModifiedSinse с этой датой и ловит ответ "304 Not Modified".
Но, судя по предлагаемому этим сервисом PHP-скрипту отдачи заголовков lastModified, создатель сервиса сам до конца не понимает принципы кэширования на стороне клиента.
Поэтому сервис не отрабатывает проверку корректности полученной даты сервером. Для полной проверки надо слать ещё 2 запроса - с датой из будущего и просто некорректной датой. И проверять код ответа сервера на 304/200.
Для "статики" мутить это бессмысленно - ЛастМодифайд корректно отдаёт сам веб-сервер, беря её из даты последнего изменения файла.
При этом, для статических файлов веб-сервер автоматически поддерживает и второй более гибкий вариант кэширования IfNoneMatch - Etag:
ETag может быть «строгим» (два документа имеют одинаковые ETags только если они совпадают побитово) или «нестрогим» (два документа имеют одинаковые ETags если они совпадают по содержанию, но могут отличаться в незначительных деталях).
Бесплатность распространения FreeBSD - вовсе не означает, что народ там работает бесплатно, про остальное - источники финансирования найдите сами, они 100% есть.
Ида, те, кто спонсирует разработку бесплатных ОС - используют его пользователей в своих целях как противовес коммерческим "Майкрософтам". То есть, вы всё-равно являетесь "товаром" в их противостоянии.
И не забывайте, что потом в бесплатным продуктам появляется куча платных фич.
PS: Сравните по возможностям "бесплатный" форум phpBB и vbulletin, сразу все станет ясно, что лучше использовать.
SF473y4ghfed, извините за оффтоп - у вас действительно такой Nic, или вы просто Xrumer-ом постите?
Возможно, стихи - не в тренде, и их никто не ищет.
Далеко не всё, а только содержимое определённых тэгов и их атрибутов. Причем, разные ПС - по разному, Например:
- Google считает содержимое выпадающего списка select - контентом страницы и ищет по нему.
- Rambler(пока работал на своём движке) считал содержимое alt контентом страницы и искал по ним.
- атрибут alt содержимым страницы в общем не является, но в некоторых случаях может стать анкором ссылки(см эксперимент Деваки).
- содержимое яваскриптов в общем не является контентом страницы(за некоторыми исключениями) и ПС по ним не ищет
Сильно зависит от того, насколько дотошно написан парсер этого сервиса - разбирает ли он страницу на элементы DOM и отличает ли содержимое тэгов от атрибутов тэгов.
Тупое регулярное выражение из preg_math() вашего сервиса может учитывать слова даже найденные в комментариях html <!-- -->
Плюс, поисковик может учитывать слова(в зависимости от того, в каком месте html он их обнаружил) совсем не так как парсер сервиса.
B cервисы - не индексируют содержимое flash, документов Word и PD, а ПС - индексируют(пытаются).
