seocore

стрелки переведут на виновное лицо, того, кто выставил на продажу этот домен, при условии, что смогут установить личность причастную к этому деянию

если SEO/продвижение - лучше избавляться от этого (просто этически), а если ссылка на веб-студию, то ничего не должно быть, если же в "окружении вкусных словечек", то уже не очень хорошо, любые ссылки направленные на манипулирование выдачей (анкорные, безанкорные, ручные\автоматические, временные\вечные) - это плохо и стоит ожидать приключений 🤪

а по манипулированию, если Вам удалось качественно повлиять на выдачу ссылками, то стоит ожидать качественного влияния в виде фильтров на Вашу площадку :D

отпишите в ПС (Яндекс) про это безобразие (через интерфейс Яндекс.Вебмастер), в случае возникновения проблем в будущем, просто сошлетесь на то сообщение, в котором вы упоминали про возникшую ситуацию

Если хотите продать сайт выгодно, то пункты 1 и 2 отпадают сразу, пункт 3 не имеет актуальности в свете таких инструментов, как www.keys.so и т.п. Подытожим, хорошие покупатели, кто реально готов покупать Ваш проект за вменяемые деньги, увидят Ваш домен просто перебрав по базе "даты регистрации" все домены за этот день, оценят видимость ключей в ПС, оценят юзабилити и качество контента (его юридическую и техническую безопасность) и только потом купят. Знаю многих, кто работает с проектами серьезно, и для них эти игры в "прятки" ничего кроме раздражения и недоверия не вызывают. Лот и продавца будут тщательно проверять в любом случае, чем больше проблем создадите покупателю, тем меньше шансов на успешную продажу по желаемой цене. А все эти сокрытия - это только для дорвейных проектов, и практически не имеют никакого смысла, так как никто не покупает "кота в мешке" за более\менее серьезные деньги.

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

Я бы для покупателей рекомендовал:

• Проверить видимость сайта в ПС по запросам, сравнить баланс (источники) между ПС, существенный перекос в любую из ПС - это признак возможных фильтров, а фильтры просто так не раздают, и если фильтр дали в одной ПС, то вполне вероятно, что его дадут и в другой, даже если это еще не случилось на момент покупки.
• Проверять ссылочный профиль проекта, чем меньше ссылок, тем лучше, не гонитесь за пузомерками, в современных реалиях это скорее рисковый фактор.
• Проверить качество и юридическую чистоту контента (источники фото\видео материалов), копипаст ли это, не цепи ли маркова или мешап (на тему дорвеев). Проверить актуальность самих материалов, не имеет смысл покупать некрополи архивных новостей за 2005-2010 годы, сайты моды прошлых лет и т.п., переделка такого контента лишена смысла, в SEO плане он не просто бесполезный баласт, он вредный баласт. В таких старых проектах ценна обычно лишь аудитория проекта (постоянная аудитория).
• Проверьте присутствие сайта в сетях контекстной рекламы, если на сайте нет РСЯ\Адсенса, то это повод задуматься над качеством проекта. Плохое расположение блоков - это плюс, так как расставив все правильно Вы просто сократите время возврата вложений.
• Пробейте продавца настолько, насколько вам доступно, зайдите на сайт, свяжитесь с хозяевами сайта (через группы в соцсетях и т.п.), удостоверьтесь, что хозяева сайта в курсе, что их сайт продают. Оплату проводите через банк, проще будет избежать возможных проблем.

правильно, объединить картинки в спрайты, сложить вместе (и сжать) css, js, ... на худой конец SPDY или HTTP/2.0 и это существенно больше пользы принесет

просто экономия при выборе SATA-HDD или SSD - это, на мой взгляд, глупо 🍿

совершенно верно, WP/DLE при создании тех же "Похожие записи" могут делать эпические выборки в БД, шутка ли - найти похожие записи к посту, когда в БД таких записей 50к, в таких условиях даже популярность не нужна, бот ПС положит все это дело, в таких играх без SSD делать нечего, или иметь дело с дорогими профессиональными программистами, час работы которых стоит как годовая оплата ВПСки на SSD, или просто идти и перекрывать вопросы нагрузки за счет огромного запаса в производительности платформы 😂

как пример - загруженность ноды, где куча ВПСок, одно дело, когда там SSD сторэдж и лимитирование каждой виртуальной машины в 2000 IOPS'ов, при реальной производительности сторэджа около 45-75к IOPS'ов, а другое дело SATA'шный RAID-10 сторэдж (пусть аппаратный с 1Гб ОЗУ кеша и прочими плюшкам), но на нем будет в лучшем случае 1200 IOPS на всю ноду

пример из практики - разница между 0.3 секунды на отработка морды Joomla и 1 секунда - почти одно и тоже? - но на практике это означает, что php-fpm/apache-форк успеет за 1 секунду обслужить в 3 раза меньше соединений, т.е. ВПС будет в 3 раза уступать в производительности... и вот эта разница между 1 секундой и 0.3 - это как раз эта самая разница в SSD-vs-SATA, так что имейте этот момент в виду 🍿

как уже выше написали, запись будет чаще, причина банальна - операции на чтение великолепно кешируются в ОЗУ на уровне ОС, чего не скажешь про кеширование на запись, часть ПО тупо дает сигналы ОС, чтобы та сбрасывала на диск (без кеширования) и т.п., в итоге, на практике - операций на запись больше, чем на чтение

даже в этом случае, статика закешируется на уровне ОС в ОЗУ (после первого обращения), а вот запись в логи пойдет без буферизации сразу на диск (правда, логи можно отключить или задать приличный буфер записи для логов, но это уже другая история, не для "из коробки" ситуаций), в итоге будет та же картинка - записи на диск больше 🍿

так по ценам это уже не актуально, SSD сейчас даже в "серверных" версиях уже стал нормой, скорее наоборот, еще надо найти сайтец\проект, которому нужно много пространства и SSD становится неприемлем по цене

картинка ни о чем вообще 🍿

SATA+SSD-кеш обычно только на чтение, и в зависимости от использования, необходимо, чтобы активная (используемая) часть диска попадала в SSD-кеш, т.е. гадание на кофейной гуще, эффективен будет кеш или нет

я бы рекомендовал HDD+SSD-кеш только на каких-то малоактивных сторэджах с массой мелких файлов, например фото, в остальных случаях лучше рассматривать только SSD

будет и еще какая, если мы, конечно, не говорим о ситуации с помещением всех данных (включая БД) в рамдиск 😂

в ряде случаев, сокращение загрузки странички с 5 секунд до 1 влияет на % отказов практически в 2 раза, скажется ли это на позициях? - уместен ли вопрос? 🍿

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

как-то так:

<?php
if($_SERVER["HTTP_CF_CONNECTING_IP"]){$_SERVER["REMOTE_ADDR"]=$_SERVER["HTTP_CF_CONNECTING_IP"];}
require_once('geoplugin.class.php');
$geoplugin = new geoPlugin();
$geoplugin->locate();
// create a variable for the country code
$var_country_code = $geoplugin->countryCode;
// redirect based on country code:
if ($var_country_code == "RU") {
header('Location: /');
}
else {
header('Location: http://facebook.com');
}
?>

в коде исказились при вставке квадратные скобки :)

дело не в MySQL, по конфигу он может сожрать только 33% ОЗУ, что не критично, а ОЗУ жрет кто-то другой

max_connections=70 - сократите тоже до 30
max_user_connections=30
join_buffer_size=1M - увеличьте до 8Мб
table_cache=512 - увеличьте до 2-4 тыс
thread_cache_size=128 - уменьшите до 30
max_allowed_packet=1M - увеличьте до 16
query_cache_limit=2M - увеличьте до 4
query_cache_size=16M - увеличьте до 64
query_cache_type=1
tmp_table_size=32M - увеличьте до 64
max_heap_table_size=16M - увеличьте до 64

• таблицы крашатся - возможно, на диске закончилось место (например: временно создается какой-то большой файл, такой как бэкап-архив, в таком случае, посмотрите на свободное место, его должно хватать на создание бэкапа, оптимально, чтобы 50% диска были свободны)
• оптимизация (дефрагментация) таблиц для innoDB неактуальна (только пересоздание), по-этому, можно не тратить время на эту операцию
• в Joomla есть поддержка xcache/memcached механизмов (их стоит поставить, я рекомендую xcache, но надо корректно настроить .var_size параметр в .ini), должно существенно сократить количество запросов к БД

глупость, так как создаете себе множество потенциальных проблем, как совет - постарайтесь развить какой-то один проект до уровня полноценного СМИ (а не покупать десятки MFA), со всей официальной составляющей, а потом ищите профильного инвестора