4X_Pro

Members
  • Content count

    13
  • Joined

  • Last visited

About 4X_Pro

  • Rank
    Пользователь

Contact Methods

  • Skype
    x4_pro

Profile Information

  • Пол
  • Местоположение
    Москва, Перово
  • Интересы
    HTML, CSS, Python, PHP, форумы, Intellect Board, machine learning, нейросети, OpenCV, когнитивистика, типологии личности, соционика, психософия, информионика, темпористика, работа мозга
  • Ваш сайт
    http://4xpro.ru
  • Специализация
    Вебмастер
  • Профиль ID
    4xpro

Recent Profile Visitors

1237 profile views
  1. Главный недостаток HTTPS — это увеличение времени ответа сервера на несколько десятков (а то и сотен, если сервер далеко) миллисекунд из-за дополнительных обменов пакетами на этапе установления SSL-сессии. Собственно, если бы не это, давно поставил бы на все свои сайты тот же Let's Encrypt или сертификат от хостера. Но с другой стороны, наличие сертификата дает возможность использовать HTTP/2 (если хостинг поддерживает или сумели настроить на своем VDS). И если на сайте много статичных файлов (картинок, CSS и т.п.), то за счет преимуществ HTTP/2 может получиться, что сайт в целом все же будет загружаться быстрее.
  2. Из всех сайтов дали +10 ИКС только одному (с 40 поднялся до 50). Причем такому, с которым я уже давно ничего не делал вообще, он просто висит и все, и посещаемость тоже на одном уровне примерно. Другой сайт по посещаемости подрос на 20%, но ИКС не поменялся.
  3. форумный движок php — / (корень) движок для форума php — / (корень) скрипт для форума на php — / (корень) скачать бесплатный движок форума — /about/ скачать бесплатный скрипт форума — /about/ скачать бесплатный форум — /about/ установить форум — /docs/install/ установить форум на сайт — /docs/install/ Проверил примерно до 450 позиции, не нашел. И вообще, сложно поверить, что запрос с 28 показами может быть столь высококонкуретным. Если рассуждать формально, то форум является частным случаем сайта. Зачем тогда вообще было отписываться? Количество сообщений увеличить? Заказать платный аудит возможности нет: проект заведомо не предполагает никакой окупаемости, поэтому я готов тратить на него сколь угодно много времени, но совершенно не готов тратить деньги.
  4. Если я правильно понял, что вы хотите, то RewriteEngine on RewriteRule ^/articles/blog/(.+)$ http://%{HTTP_HOST}/articles/$1 [R=301,L] (или https:// вместо http://, если сайт через него работает). В этом случае поисковики поймут, что адрес страницы изменился. И естественно, нужно сделать необходимые настройки в CMS. Если не сработает, уберите / перед первым articles.
  5. Есть сайт intbpro.ru — сайт поддержки моего самописного форумного движка. Вроде поисковиками проиндексирован нормально, около 200 страниц в индексе. В Вебмастере Яндекс из ошибок — только отсутствие description у нескольких страниц, Google ругается на то, что 92 страницы проиндексированы, несмотря на блокировку в robots.txt. Новые страницы заходят в индекс нормально. Некачественными в ЯВМ признано всего 4 страницы. Здешний анализатор выдает 96% качества сайта. Проблема в том, что сайт не появляется в выдаче даже по таким НЧ-запросам как «движок форума php» или «скрипт форума php», даже на каких-нибудь 120-х позициях, где выдается вообще мусор. Чем это может быть вызвано? Есть две версии: либо влияет большое количество ссылок вида /раздел/тема/new.htm, которые делают 302 редирект на последнее сообщение в каждой теме, либо влияние старого заброшенного сайта intboard.ru, на котором размещалась предыдущая версия движка. Недавно еще ИКС обнулился, хотя изначально был 10.
  6. Вполне могло быть, что конфиг где-то закешировался (у меня что-то подобное в свое время было с punBB, правда, там кешировались не данные для подключения к БД, а настройки). Попробуйте очистить каталог cache.
  7. Вообще-то есть ограничение на количество одновременных подключений к сайту (у большинства современных броузеров по умолчанию оно равно 8). Соответственно, если у нас 15 CSS, то одновременно качаются в лучшем случае 8 штук, а остальные 7 — в очереди. А вообще, советую посмотреть процесс загрузки сайта с помощью вот этого сервиса: WebPageTest, он дает четкую диаграмму что после чего и в каком порядке загружается, и сколько реально на это уходит времени.
  8. Если сайт на самописном движке, то найти описание формата RSS, разобраться с ним, сесть и написать такое. Там все очень просто на самом деле: нужно получить из базы список новостей и циклом для каждой из них сгенерировать определенный XML-код, а потом вставить все это в один XML-документ. Если на чем-то более известном (всякие Joomla/WP/Drupal) , то там это либо есть изначально, и нужно просто добавить ссылку на URL, по которому выдается RSS-поток, либо нужно поставить соответствующий plugin.
  9. На мой взгляд, основная причина тут в следующем: крупные системы статистики (типа того же LI) умеют обнаруживать поисковых роботов и не учитывать их в статистике, а plug-in — нет (или умеет, но не всех, скажем, знает Google, но не знает Яндекса). Что касается пользователей онлайн, то там разброс объясняется тем, что пользователями онлайн считаются не те, у кого сейчас открыта страница (из-за сообенностей протокола HTTP такое без JavaScriptа и постоянных запросов к серверу отследить вообще нельзя), а те, кто загрузил страницу за последние несколько минут. Для LI этот период указан явно: 15 минут, для plug-inа он может быть больше (скажем, 20 или 30), отсюда и разница в статистике.
  10. Возможно, дело во временной недоступности хостинга (в какой-то момент отвалилась база или при росте нагрузки при прохождении робота сервер начинает выдавать страницу с ошибкой с некорректными заголовками). Еще советую посмотреть в error_log на сервере, поискать там ошибки при обращении к этим страницам. Возможно, это как-то прояснит ситуацию.
  11. Дольше -- очень маловероятно. Дело в том, что каждое обращение к отдельному файлу -- это еще и передача и прием HTTP-заголовков, которые дают обычно около 1K лишнего траффика на запрос (не говоря уж о том, что сервер выдает один большой файл быстрее за счет того, что для этого нужна всего одна операция открытия и чтения файла, а не 15, которые к тому же могут быть разбросаны по всему диску). Поэтому CSS объединять надо. С JavaScript не все так однозначно, там важнее не столько объединить файлы, сколько сделать асинхронную загрузку, то есть сначала отображается страница сайта, потом догружаются JavaScript (тут может очень хорошо помочь скрипт под названием head.js).
  12. Полагаю что никак. Сам придерживаюсь такого правила: сайт должен быть максимально похож на то, как было во времена сайтов на статичных HTML. Это и тем, кто в Интернете давно, привычнее, и меньше вероятность вызвать глюки у какого-либо бота. Поэтому делаю так: если URL содержит в конце символ /, то расшрения нет, если не содержит, то добавляю расширение .htm. Например, /mypage/ и /mypage/about_me.htm. А вот адреса вида /mypage/about_me очень раздражают, создается ощущение недоделанности какое-то.
  13. Улетел под АГС один форум на phpBB, которым я не занимался с 2012 года (и активность была полностью на нуле), и с которого приторговывал ссылками: осталось всего 4 страницы в индексе. Остальные сайты вроде живы, кое-какие даже весьма ощутимо подросли в выдаче.