Ну неужели это так сложно понять???...
Алгоритм ранжирования ПСов - черный ящик. СЕОшники могут лишь предполагать и проводить эксперименты, на основании которых делают выводы(иногда не совсем правильные). А то что написано в книгах...
может РОТ13, может открытым кодом, может и бейс64!
Не парьтесь сами и других не парьте. Заплатите денег прогеру и все. А так больше нервов потратите.
ТС, а если плотность ключа 8%, а ключей 13, то получается, что статья на 94% состоит из ключей??? Учите мат.часть. Еще скажите спасибо человеку, за то что ссылку дал.
А кто Вам даст внятный ответ? Правильно, работники яндекса, которые знают алгоритм ранжирования. Вот им тогда и задавайте такие вопросы.
ТС, в плагине может быть хук на wp_footer или еще что-то, что отображается позже этой ссылки. И в этом самом хуке проверяется наличие ссылки в контенте.
А может ТС 2-ой ВК делает:D
Я думал что мускул это реляционная БД:)
Не надо ничего мудрить! Делайте новую запись.
Пусть юзер номер 12 состоит в группах 3, 5, и 42
То делаем 3 записи в БД:
`userID` - `groupsID`
12 - 3
12 - 5
12 - 42
На большой БД при WHERE спасут индексы, для LIKE и REGEXP они не помогут.
Зависит от юзера:
1) у ПХП и директорий/файлов один и тот же юзер
2) Владелец файлов/директорий и ПХП разные юзеры.
1случай - права по большому счету пофиг. в ПХП есть функция
bool chmod ( string $filename , int $mode )
2случай - придется больше внимания уделить расстановки прав, так как влияет на безопасность.
Не так уж и давно тут человек рассказывал про БД(1 таблица) весом 80ГБ и размером около 2млрд записей. Ему говорили, что надо упростить архитектуру(сгрупировать однотипные данные и создать для каждой группы свою таблицу), а он не в какую:)
Вы хотите сказать ПСам, что гавноконтент переехал на главную? Ставьте 410, так в данной ситуации будет лучше, наверное;)
для этого можно посмотреть спецификацию RFC2616;)
Я за 410, так как считаю это более правильно. А вот как это интерпритируется поисковиками - хз.
