Хочу добавить лично от себя: Я не собираюсь защищать Drupal в плане нагрузки на базу данных. Это действительно может оказаться тяжелым минусом его использования, и мне на своем опыте пришлось пройти через то же самое, что и автору изначальной статьи. Однако я не склонен поддерживать и тех оголтелых критиканов, которые называют его архитектуру принципиально неудачной. После углубленного знакомства с ней я пришел к выводу, что архитектура как раз чрезвычайно продумана и там нет кода, не оправданного целями. Я убежден, что критиковать не знакомую архитектуру попросту глупо и именно это выставляет некоторых критиков в невыгодном свете. У меня даже появились подозрения, что лагерь ярых противников Drupal состоит из людей, которые просто не смогли его понять и освоить. Поскольку будучи в курсе архитектуры и инструментария этого CMF, вряд ли можно ожидать от него больше, чем осмысленно занесено туда разработчиками. Я уверен, что Drupal имеет свою нишу и чертовски хорош в ней, но затыкать им любую дырку попросту неправильно. Как нельзя абстрактно выбирать лучшего из автомобилей F1 и скажем Hammer — конкретное применение и объяснит что в данной ситуации выгоднее, даже не придется устраивать соревнования, если знаешь особенности этих ТС. Точно так же и с движками сайтов и это нельзя сбрасывать со счетов. На мой взгляд автор статьи проделал совершенно правильную и осмысленную работу, но сделал заступ в оценках, чем и вызвал некорректную местами полемику.
До этого момента мне казалось, что вы знакомы с Drupal
Расскажите мне кто-нибудь, как вообще это можно использовать? Сколько кода надо написать, что бы полноценно анализировать Sql-запросы и тем более править их на лету?
Но после, извините, ваши слова перестали восприниматься как адекватные. Ну что ж, раз вы не знаете ничего про event-driven архитектуру, то не в теме о Drupal ее и объяснять, но если вы не увидели в Drupal своего ORM, архитектура которого и позволяет переписывать запросы, то какой смысл с вами общаться, если вы просто выдумываете аргументы от незнания?
Ну и туда же идут такие же кривые хуки типа form_alter (парни, в нормальном фреймворке вы либо расширяете объект с формой, либо если речь о внешнем виде, то наследуете/переписываете шаблон этой формы, а не ковыряетесь в пяти мерном массиве). Что касается хуков типа js_alter/css_alter — опять же, умные ребята просто делают систему шаблонов/виджетов и про сборке страницы автоматически учитывают все зависимости. Ну или хотя бы берут уже готовый XSLT — через него можно шаблоны хоть наизнанку выворачивать.
Слова ярого «тупоконечника» у которого «остроконечники» виноваты в том, что бьют яйцо не с той стороны. Хотите пользоваться XSLT и подхватывать налету несуществующие css/js файлы, ваше право, а разработчики Drupal дали разработчику любого модуля изменять логику генерации страницы задавая динамически наследование логики. Я бы с удовольствием посмотрел бы как вы гоняли один объект, той же формы, через 20 модулей (только паре из которых нужно эту форму трогать) добавляя и меняя его свойства. Если считаете, что event-driven способ делать модульность хуже, чем многократные наследования или полный конвейер обработки каждой сущности, то попробуйте это как-то проиллюстрировать что ли.
API Друпала — отдельная кривая вещь. Хотите получить ноду по id? В руководстве АПИ прямо написано, что для этого лучше использовать прямые запросы, так как метод АПИ выбирает много данных и медленно работает.
Тут вы путаете теплое с мягким. Функция node_load() загружает результат прохода через все хуки, модифицирующие node, а прямой запрос достанет только то, что вы в него внесете без учета данных, добавленных другими модулями. То есть вы рискуете вообще отключить работу сторонних модулей в этом действии. Для некоторых задач оптимизации это имеет смысл, но в основном ничего кроме проблем и багов не сулит. Перед тем как критиковать этот подход дайте себе отчет, что вы просто не хотите соблюдать правила, и нарушая их получаете предсказуемые проблемы.
SELECT s.lid, t.translation, s.version FROM {locales_source} s LEFT JOIN {locales_target} t ON s.lid = t.lid AND t.language = :language WHERE s.source = :source AND s.context = :context AND s.textgroup = 'default'
(запрос из locale.module, видимо для перевода строк). Для незнакомых с MySQL объясняю — при переводе строки мало того, что Друпал делает запрос в БД (да еще и с джойном, чтобы не отпимизировался), так еще и с поиском по текстовому (до 65536 символов) полю source. Любой человек, кто прочел хотя бы полглавы мануала по MySQL будет за такое бить монитором по голове. Gettext герои-друпаловцы решили побрезговать, что нам стоит каждую строчку из БД выдергивать.
Первый достойный пример недостатков drupal. Конечно про gettext вы вспомнили, учтя возможность вносить перевод для неограниченного числа языков через админку? Решение разработчиков drupal и меня в свое время огорчило, хотя я пошел немного дальше, чем вы и обнаружил в коде и другой запрос
// Refresh database stored cache of translations for given language.
// We only store short strings used in current version, to improve
// performance and consume less memory.
$result = db_query("SELECT s.source, s.context, t.translation, t.language FROM {locales_source} s
LEFT JOIN {locales_target} t ON s.lid = t.lid AND t.language = :language WHERE s.textgroup = 'default'
AND s.version = :version AND LENGTH(s.source) < :length", array(':language' => $langcode,
':version' => VERSION, ':length' => variable_get('locale_cache_length', 75)));
foreach ($result as $data) {
$locale_t[$langcode][$data->context][$data->source] = (empty($data->translation) ? TRUE : $data->translation);
}
cache_set('locale:' . $langcode, $locale_t[$langcode]);
Надо ли объяснять, что это означает, что некоторые переводы загружаются (вы сами устанавливаете какие руководствуясь длинной для удобного распределения оперативной памяти) одним запросом? Кстати это может оказаться производительнее, чем gettext и одновременно гибче. Но беда, которую вы разглядели грозит тем, у кого variable_get('locale_cache_length', 75) вернет что-то близкое к нулю. Если вы считаете, что этот механизм при его гибкости не имеет права на существование, то пожалуйста аргументируйте, мне действительно интересно узнать что-то более эффективное и одновременно удобное.
Я уж молчу, что в нем нет ни моделек, ни ORM, ни валидаторов, ни нормальной работы с формами, ни системы views/widgets, ни наследуемых шаблонов, ни контроллеров, ни MVC, вообще ничего, чем все прогрессивное человечество пользуется в последние 10 лет.
Тут вы явно спорите о вкусах. ORM и валидаторы есть, просто они отвечают не привычным для вас потребностям. (Кстати отрицать существование ORM в продукте где один код используется минимум для трех заявленных СУБД, это слегка необдуманно на мой взгляд). Идея моделей не используется поскольку противоречит некоторым избранным стратегическим решениям, не хочу на этом заострять, вы можете найти это в словах самих разработчиков. Шаблоны Drupal реализуют совсем другую концепцию нежели Django. И вместо вертикального наследования они усилены горизонтальным. Вряд ли привычные вам шаблонизаторы дают возможность модулям влиять на рендеринг целых классов элементов страницы вне зависимости от даже используемой темы. Советую познакомиться с этой системой хотя бы для «общего развития», чтобы раздвинуть рамки узкого понимания шаблонизации. Опять же вызвано это неимоверной гибкостью. Причем «прогрессивное человечество» скорее всего еще будет иметь возможность оценить эту гибкость по мере последующего роста производительности серверов, а сейчас это просто футуристические эксперименты, имеющие полное на мой взгляд право на существование с учетом хорошего кеширования. И зря вы пытаетесь натянуть новые идеи на старый опыт. Это так же неэффективно, как оценивать Erlang с точки зрения парадигмы PHP.
Вы дважды упомянули хуки в странном контексте подпорок. Хуки в Drupal это обработчики сообщений event-driven архитектуры. Может вы просто не представляете себе насколько это эффективное решение, что делаете столь странные заключения. Могу лишь посоветовать познакомиться с понятиями перед тем, как их критиковать.
1) Вы нарочно не делаете разницы между обобщением и конкретикой? Если хотели обобщать, так и я обобщаю: гениальный сайт получит свою аудиторию безо всякого SEO. Хотите конкретики — говорите конкретно, в чем заключается гениальный студенческий проект, который не идет только потому, что не хватает посетителей из поисковиков. Тогда и обсудим. Может вы просто не знаете никаких других каналов привлечения. А так ваши доводы про бабушек и мам мягко говоря оторваны от предмета обсуждения.
2) Я без копейки денег вложенных в поиск вывел контентный сайт на самоокупаемость за 4 месяца. В рекламу вкладывался, в покупку и бомбинг ссылок — нет. Но это мелочь. Для продвижения другого, более крупного проекта не использовал ни копейки на SEO, но поработать с каналами привлечения аудитории пришлось долго и кропотливо. Сейчас там 35к+ уников в сутки. И это всё после нескольких лет практики того самого, серого, SEO, так что я не всегда был на стороне критиков и хорошо знаю этот мир изнутри.
Контекстная реклама это официальный рекламоноситель и цивилизованный инструмент для всех желающих продвинуться за деньги. Если у вас не достаточно денег для продвижения рекламой, то зачем вы вообще нужны в выдаче по логике сеошников, ссылающихся на это habrahabr.ru/blogs/seo_smo/131568/#comment_4368446
Ну тогда поспорьте с ними что-ли. А заодно и нам раскройте противоречие заложенное в желании конкурировать деньгами, но без помощи предназначенной для этого контекстной рекламы.
К чему такая педантичность? Здесь же интеллигентные люди, которые могут вычленять информацию из контекста. Да и вы ведь не робот — умеете это делать. Раз здесь идет речь о SEO, но никоим образом не задета, скажем так, деловая иерархия американского общества, то ведь не сложно сделать поправку на естественное человеческое чувство — лень переключать раскладку и принять для себя тот факт, что упомянутые на этой странице «СЕО» являются на самом деле SEO. Это фактически та же ситуация, что и с буквой Ё. Мы ее можем не писать, поскольку людям (в противовес машинному интеллекту) так проще, а путаницы наоборот практически не возникает.
Вы зря приписываете мне бегатню в розовых очках, с попутным разрушением до основания. :)
То, что я написал, уже давно заявлено всякими Мэтами Катсами и прочими поисковыми спикерами. Им в большой степени наплевать на то кто из «однояйцевых» сайтов станет выше по ранжиру. Они давно создали для таких механизм конкуренции — контекстную рекламу. И там всё, как вы хотели — кто больше заплатил, тот и выше. Что же останавливает наших горе коммерсантов от использования этого механизма? Жадность. Оказывается как доходит до настоящей конкуренции бабками всем становится жалко условные 10 баксов за переход. И пока загадить выдачу дешевле, они плевали на цивилизованную конкуренцию, о которой вы так удачно размышляете.
Знаете, я не боюсь выглядеть не достаточно прагматичным, мечтая о том, что в выдаче останутся те, кто больше сделал для клиента, и я с нетерпением жду от поисковиков инноваций в этом направлении.
Да! Интернет глазами поисковиков «состоит из ссылок». То есть они помогают отнести страницу к определенной тематике.
Но, в сео — это работа не только с ссылками, это работа с текстом, работа с оформлением страницы, с различными метоописаниями. Это адаптация сайта к реалиям интернет. Какие то вещи мы показываем людям, но не показываем поисковикам, что бы не было дублей. Проводятся работы чтобы помочь поисковику понять что у нас за сайт.
С таким белошляпочничеством я спорить не стал бы, но ТС пытается оправдать всех тех, кто грызется за топ бабками, не вкладывая туда интеллекта и артистизма. Пытается оправдать SEO-шников тем, что им хочется кушать и что раз другие обманывают, то почему бы не обманывать тоже, ведь они-то не перестанут. А потом еще пытается примазать мошеннические методы к честной коммерции, с чем я в корне не согласен.
Поисковики постоянно дорабатывают свои алгоритмы. Почитайте про то как они отслеживают отказы. Например ищем в яндексе «какую то ерунду», получаем топ 10. Зашли на сайт с 1го места, потусили там 2 секунды и поняли сайт совсем не о том, нажали на 2ю ссылку — вот яндекс понял, что это отказ. И сайт спустится с 1го места, его займет другой ресурс, который дал меньшее количество отказов.
Не выдавайте пожалуйста фантазии за алгоритмы — некоторые могут воспринять в качестве откровения. Многие глядя на серп привычным жестом открывают сразу 4-5 ссылок в других табах, не отвлекаясь от чтения страницы поисковика. И, будь вы правы, лидеры бы постоянно попадали под санкции из-за конфуза, что после их ссылки почти сразу была нажата ссылка более слабого конкурента. Если подобный механизм и существует (что кстати пару раз представители поисковиков отрицали, но с них станется), то основан он не на кликах по серпу, а на статистике из счетчиков от тех же поисковиков — Google Analytics и Yandex Metrika. И действовать стало быть может только на те сайты. где они установлены. (кстати я только что выдал идею, которую в данный момент проверяю экспериментами на живой публике)
Мир не стоит на месте. А сео это огромный набор дисциплин и инструментов, и не всегда связан с обманом. Так как если правила игры одинаковы для всех, тот тут нет обмана.
Правило «кто сильнее, тот и прав» одинаково для всех, однако наша цивилизация ограничивает искусственно его действие. Если вам нужен более полный список ограничений наложенных на общие для всех правила, прочтите уголовный кодекс. А если захотите разобраться в том, какая рекламная деятельность законна, а какая нет, прочтите закон о рекламе. Этого вполне может хватить, чтобы вы самостоятельно смогли отличить допустимые методы SEO от аморальных и незаконных.
Простите, что не буду комментировать догматизм трех последних абзацев в стиле Капитана Очевидность. Замечу только, что если вы решили этим проиллюстрировать отношение к моим словам, то вы их явно не поняли.
По первому уж и не знаю как так сформулировать, чтобы до вас дошло — sitemap.xml не дает никаких преимуществ. Рейтинг, который вы там указываете играет (и то очень слабо) только на выбор из вашего сайта одной страницы из нескольких возможных для серпа по определенному запросу. На позицию в серпе это не влияет, а нужно лишь для того, чтобы исправить ваши сеошные ошибки в продвижении конкретных страниц, когда вы сами допустили, что одному запросу с вашего сайта соответствует кроме целевой еще какая-то «левая» страница. И то это не сработает, если «левая» страница покажется поисковику более релевантной. Да, вы этим помогаете поисковику, но так, как надо ему, а не как хотелось бы вам. Хватит боготворить sitemap.xml, лучше для проекта подумайте о реализации интересов аудитории. Поверьте, то что я тут пишу, я знаю на опыте продвижения новостного ресурса с нуля в лидеры региона, за время раскрутки которого не было куплено ни одной ссылки, хотя поисковики его сейчас «любят».
А почему вы считаете, что рассылка по знакомым непременно закончится на первом же шаге? Если ваш «великолепный проект» действительно нужный, то многие из них разошлют по своим знакомым и при указанных вами условиях пройдет первичная лавина интереса. Если всё в порядке, будет и вторичная, а это даже с учетом легчайшего следа на том же хабре уже сулит огромной аудиторией. И при том, чот это не единственное, что ваша гипотетическая компания может сделать совершенно законно и не нарушая морально-этических рамок.
Просто SEO это инструмент людей, лишенных фантазии и креатива — по их мнению бабки решают, даже с учетом рисков. И те, кто привык полагаться на SEO вместо настоящей работы с интересами своей аудитории пытаются оправдаться такими топиками, как этот. Вот и вся возня. Лично я не против отстройки взаимодействия с поисковиками, но не считаю ее чем-то большим, чем смазка основного маховика привлечения. Не вижу смысла ни боготворить смазку ни строить стратегию на ней. При этом ссылок я не покупаю и не продаю — то есть тем самым SEO, как его понимают многие, не занимаюсь.
Вы искренне не понимаете разницу между рекламой и обманом? Вам не известно понятие «недобросовестная реклама»? Что же вы всю рекламу к ней относите, действительно не видите грани? Или это такой метод дискуссии — перегнуть палку до предела, насколько бы не отвернули, часть позиций не отыграют?
Реклама это не SEO. И если в рекламе вы не опускаетесь до обмана и подтасовок, то к вам никаких претензий. Но SEO это подтасовка, аналог недобросовестной рекламы. Разве так сложно понять разницу?
А вы не обобщайте, а посмотрите по конкретике. недобросовестная реклама незаконна, Обман в информировании потребителя относительно потребительских свойств товара и свойств продавца/изготовителя незаконен. Всё это с легкостью квалифицирует SEO, как противозаконные действия в приложении к бизнесу. Вот только к интернету пока относятся не серьезно и вы еще не ощущаете проблем. Но и это в какой-то момент закончится.
Притянуто за уши.
Но после, извините, ваши слова перестали восприниматься как адекватные. Ну что ж, раз вы не знаете ничего про event-driven архитектуру, то не в теме о Drupal ее и объяснять, но если вы не увидели в Drupal своего ORM, архитектура которого и позволяет переписывать запросы, то какой смысл с вами общаться, если вы просто выдумываете аргументы от незнания?
Слова ярого «тупоконечника» у которого «остроконечники» виноваты в том, что бьют яйцо не с той стороны. Хотите пользоваться XSLT и подхватывать налету несуществующие css/js файлы, ваше право, а разработчики Drupal дали разработчику любого модуля изменять логику генерации страницы задавая динамически наследование логики. Я бы с удовольствием посмотрел бы как вы гоняли один объект, той же формы, через 20 модулей (только паре из которых нужно эту форму трогать) добавляя и меняя его свойства. Если считаете, что event-driven способ делать модульность хуже, чем многократные наследования или полный конвейер обработки каждой сущности, то попробуйте это как-то проиллюстрировать что ли.
Тут вы путаете теплое с мягким. Функция node_load() загружает результат прохода через все хуки, модифицирующие node, а прямой запрос достанет только то, что вы в него внесете без учета данных, добавленных другими модулями. То есть вы рискуете вообще отключить работу сторонних модулей в этом действии. Для некоторых задач оптимизации это имеет смысл, но в основном ничего кроме проблем и багов не сулит. Перед тем как критиковать этот подход дайте себе отчет, что вы просто не хотите соблюдать правила, и нарушая их получаете предсказуемые проблемы.
Первый достойный пример недостатков drupal. Конечно про gettext вы вспомнили, учтя возможность вносить перевод для неограниченного числа языков через админку? Решение разработчиков drupal и меня в свое время огорчило, хотя я пошел немного дальше, чем вы и обнаружил в коде и другой запрос
// Refresh database stored cache of translations for given language.
// We only store short strings used in current version, to improve
// performance and consume less memory.
$result = db_query("SELECT s.source, s.context, t.translation, t.language FROM {locales_source} s
LEFT JOIN {locales_target} t ON s.lid = t.lid AND t.language = :language WHERE s.textgroup = 'default'
AND s.version = :version AND LENGTH(s.source) < :length", array(':language' => $langcode,
':version' => VERSION, ':length' => variable_get('locale_cache_length', 75)));
foreach ($result as $data) {
$locale_t[$langcode][$data->context][$data->source] = (empty($data->translation) ? TRUE : $data->translation);
}
cache_set('locale:' . $langcode, $locale_t[$langcode]);
Надо ли объяснять, что это означает, что некоторые переводы загружаются (вы сами устанавливаете какие руководствуясь длинной для удобного распределения оперативной памяти) одним запросом? Кстати это может оказаться производительнее, чем gettext и одновременно гибче. Но беда, которую вы разглядели грозит тем, у кого variable_get('locale_cache_length', 75) вернет что-то близкое к нулю. Если вы считаете, что этот механизм при его гибкости не имеет права на существование, то пожалуйста аргументируйте, мне действительно интересно узнать что-то более эффективное и одновременно удобное.
Тут вы явно спорите о вкусах. ORM и валидаторы есть, просто они отвечают не привычным для вас потребностям. (Кстати отрицать существование ORM в продукте где один код используется минимум для трех заявленных СУБД, это слегка необдуманно на мой взгляд). Идея моделей не используется поскольку противоречит некоторым избранным стратегическим решениям, не хочу на этом заострять, вы можете найти это в словах самих разработчиков. Шаблоны Drupal реализуют совсем другую концепцию нежели Django. И вместо вертикального наследования они усилены горизонтальным. Вряд ли привычные вам шаблонизаторы дают возможность модулям влиять на рендеринг целых классов элементов страницы вне зависимости от даже используемой темы. Советую познакомиться с этой системой хотя бы для «общего развития», чтобы раздвинуть рамки узкого понимания шаблонизации. Опять же вызвано это неимоверной гибкостью. Причем «прогрессивное человечество» скорее всего еще будет иметь возможность оценить эту гибкость по мере последующего роста производительности серверов, а сейчас это просто футуристические эксперименты, имеющие полное на мой взгляд право на существование с учетом хорошего кеширования. И зря вы пытаетесь натянуть новые идеи на старый опыт. Это так же неэффективно, как оценивать Erlang с точки зрения парадигмы PHP.
2) Я без копейки денег вложенных в поиск вывел контентный сайт на самоокупаемость за 4 месяца. В рекламу вкладывался, в покупку и бомбинг ссылок — нет. Но это мелочь. Для продвижения другого, более крупного проекта не использовал ни копейки на SEO, но поработать с каналами привлечения аудитории пришлось долго и кропотливо. Сейчас там 35к+ уников в сутки. И это всё после нескольких лет практики того самого, серого, SEO, так что я не всегда был на стороне критиков и хорошо знаю этот мир изнутри.
Ну тогда поспорьте с ними что-ли. А заодно и нам раскройте противоречие заложенное в желании конкурировать деньгами, но без помощи предназначенной для этого контекстной рекламы.
То, что я написал, уже давно заявлено всякими Мэтами Катсами и прочими поисковыми спикерами. Им в большой степени наплевать на то кто из «однояйцевых» сайтов станет выше по ранжиру. Они давно создали для таких механизм конкуренции — контекстную рекламу. И там всё, как вы хотели — кто больше заплатил, тот и выше. Что же останавливает наших горе коммерсантов от использования этого механизма? Жадность. Оказывается как доходит до настоящей конкуренции бабками всем становится жалко условные 10 баксов за переход. И пока загадить выдачу дешевле, они плевали на цивилизованную конкуренцию, о которой вы так удачно размышляете.
Знаете, я не боюсь выглядеть не достаточно прагматичным, мечтая о том, что в выдаче останутся те, кто больше сделал для клиента, и я с нетерпением жду от поисковиков инноваций в этом направлении.
С таким белошляпочничеством я спорить не стал бы, но ТС пытается оправдать всех тех, кто грызется за топ бабками, не вкладывая туда интеллекта и артистизма. Пытается оправдать SEO-шников тем, что им хочется кушать и что раз другие обманывают, то почему бы не обманывать тоже, ведь они-то не перестанут. А потом еще пытается примазать мошеннические методы к честной коммерции, с чем я в корне не согласен.
Не выдавайте пожалуйста фантазии за алгоритмы — некоторые могут воспринять в качестве откровения. Многие глядя на серп привычным жестом открывают сразу 4-5 ссылок в других табах, не отвлекаясь от чтения страницы поисковика. И, будь вы правы, лидеры бы постоянно попадали под санкции из-за конфуза, что после их ссылки почти сразу была нажата ссылка более слабого конкурента. Если подобный механизм и существует (что кстати пару раз представители поисковиков отрицали, но с них станется), то основан он не на кликах по серпу, а на статистике из счетчиков от тех же поисковиков — Google Analytics и Yandex Metrika. И действовать стало быть может только на те сайты. где они установлены. (кстати я только что выдал идею, которую в данный момент проверяю экспериментами на живой публике)
Правило «кто сильнее, тот и прав» одинаково для всех, однако наша цивилизация ограничивает искусственно его действие. Если вам нужен более полный список ограничений наложенных на общие для всех правила, прочтите уголовный кодекс. А если захотите разобраться в том, какая рекламная деятельность законна, а какая нет, прочтите закон о рекламе. Этого вполне может хватить, чтобы вы самостоятельно смогли отличить допустимые методы SEO от аморальных и незаконных.
По первому уж и не знаю как так сформулировать, чтобы до вас дошло — sitemap.xml не дает никаких преимуществ. Рейтинг, который вы там указываете играет (и то очень слабо) только на выбор из вашего сайта одной страницы из нескольких возможных для серпа по определенному запросу. На позицию в серпе это не влияет, а нужно лишь для того, чтобы исправить ваши сеошные ошибки в продвижении конкретных страниц, когда вы сами допустили, что одному запросу с вашего сайта соответствует кроме целевой еще какая-то «левая» страница. И то это не сработает, если «левая» страница покажется поисковику более релевантной. Да, вы этим помогаете поисковику, но так, как надо ему, а не как хотелось бы вам. Хватит боготворить sitemap.xml, лучше для проекта подумайте о реализации интересов аудитории. Поверьте, то что я тут пишу, я знаю на опыте продвижения новостного ресурса с нуля в лидеры региона, за время раскрутки которого не было куплено ни одной ссылки, хотя поисковики его сейчас «любят».
Просто SEO это инструмент людей, лишенных фантазии и креатива — по их мнению бабки решают, даже с учетом рисков. И те, кто привык полагаться на SEO вместо настоящей работы с интересами своей аудитории пытаются оправдаться такими топиками, как этот. Вот и вся возня. Лично я не против отстройки взаимодействия с поисковиками, но не считаю ее чем-то большим, чем смазка основного маховика привлечения. Не вижу смысла ни боготворить смазку ни строить стратегию на ней. При этом ссылок я не покупаю и не продаю — то есть тем самым SEO, как его понимают многие, не занимаюсь.