Зависит от бизнеса его условий, его фактической локации и прочих обстоятельств, которые в том числе касаются разработки, бюджетов и руководства.
Как выше отметил Владимир - для Яндекса приоритетны поддомены, если есть фактическая возможность закрепить региональность. В этом смысле возможность регионального ранжирования через поддомены это ключевая точка роста для прогнозируемого трафика.
Безусловно есть и конечно все их длинным списком и подробными объяснениями излагать вряд ли будут.
Ключевые моменты в аффилированности (хотя Яндекс сейчас на это закрывает глаза), в дублированности контента (потому что как чаще всего товарный набор один и тот же во всех регионах), в региональной структуре, если она имеет необходимость.
Здесь много нюансов на стыке офферов и товарных элементов, но разбирать всё это имеет смысл только применительно к конкретике бизнеса.
Обсуждать особенности у некой умозрительной бизнес конструкции - это всё равно, что натягивать невидимые штаны на сферического коня в вакууме - спора и дискурсов c какой стороны это делать - масса, а полезности - ноль.
Владимир правильно вам намекнул - желаете сделать всё правильно, наймите опытного специалиста. Желаете разобраться самостоятельно - пробуйте, делайте и в конкретике рабочих данных задайте более конкретные вопросы.
Так более вероятно получить более точные и предметные советы.
Главной вопрос - для чего?
Оказать психотропное воздействие на потенциального противника НАТО?
Ну мы то точно знаем, что земля не плоская, поэтому этот абсурдный тезис рассматривать не стоит, а вот то, что у ряда программистов есть свои суждения в отношении того, что PHP не в полной мере является языком программирования и на это есть веские основания - это любопытно.
Но сейчас эту тему я обсуждать не хочу, это просто как дополнение к неочевидным особенностям.
Хорошо :) Тогда на всякий случай я обозначил свою, раз уж я себя им назвал :)
Пожалуйста.
Штатная функциональность это явные рабочие решения, определённые возможностями движка на уровне доступных пользовательских изменений через административную часть, либо дополняющие административные элементы.
Например, в штатной функциональности заявлено, что в административной части можно производить заполнение мета данных OpenGraph и при этом есть соответствующие поля, где в пользовательском режиме можно их активировать и заполнить.
При этом заполнение может быть уникальным, а может быть рекурсивным.
Вот это штатная функциональность.
Когда я вижу, что в административной части CMS не поддерживается работа с OpenGraph данными, я вижу, что нет у движка такой штатной (т.е. заранее определённой) возможности. И тогда я формирую ТЗ программисту, чтобы он это реализовал, если в этом есть рабочая необходимость.
Здесь могут быть варианты. Это штатная возможность может быть реализована в базовой версии, а может быть предусмотрена через установку доп. плагинов и компонентов.
Если вы просто переключаете плагины и темы, то их общую совокупность можно назвать штатными функциональными возможности. Но если мы рассматриваем какую-то базовую часть движка вне функциональных дополнений, то штатными функциями будут только те, что обеспечивает базовый движок.
Cюда же можно добавить мнение, что PHP не является полноценным языком программирования.
В чём странность?
Определённая штатными возможностями CMS.
Полагаю, что это описка и вы имели ввиду "стили".
Да, в этом смысле я и отвечаю не предыдущее замечания, что в широкой трактовке даже изменения CSS уже будет своего рода "самописом".
Давайте посмотрим, какое определением предложит нам поиск,
Пожалуй, соглашусь.
Справедливо. В этом смысле любые вносимые изменения, не определённые типовой функциональностью уже являются самописом.
Довольно сумбурный опрос. Непонятно, кто целевая аудитория опроса, непонятно событие вследствие которого опрашиваемый должен перейти на самопис, непонятна общая задача опроса.
Примерно тоже самое, что спросить "По каким причинам вы всё же позвонили сантехнику?"
Но попробую поучаствовать.
Как вебмастер и как интернет-маркетолог (со специализацией SEO) я никуда не переходил и переходить не собираюсь.
Если моя задача сделать нетребовательный, но вполне современный статичный сайт, я беру CMS Joomla + набор необходимых дополнений к нему.
Если задача интернет-магазин, то уже скорее OpenCart.
Если я подключаюсь к уже готовому проекту как интернет-маркетолог, то меня никто про мои предпочтения не спрашивает. Приходится работать с тем, что есть, включая самопис.
Если это большой проект с нагруженным функционалом, то скорее всего это самопис.
В любом случае рабочее взаимодействие от меня как правило состоит из формирования ТЗ заданий программисту и здесь уже программист решает, какой он будет использовать движок (если будет), какой фреймворк и как это программно будет решаться. Моя задача проверить функциональное исполнение и выполнять координирующую функцию.
Или в принципе это опрос для программистов?
Ну это как в детстве, если закрыл глаза, то думаешь, что всякая нечисть из комнаты ночью пропадает.
Примерно также надеяться, что если Метрику убрал, то и боты заходить не будут.
Всё это временно. Без понимания того, что пользователи делают на твоём сайте полноценно развивать сайт невозможно, а для этого нужны счётчики и внутренняя аналитика.
Там здесь никаких идеалов, одна сплошная практика.
И не только они, но в целом верно.
Изначально вопрос был не в этом, изначально вопрос в том, что более приоритетно.
Без части коммерческих можно вполне быть и даже уверенно занимать топы, а вот без стабильных поведенческих в топы, даже с очень хорошо базой по коммерческим не зайти.
