Опрос: мультисайтовость - нужно ли кому-то?

город с населением 180к, сделал сайт год назад. Запросов тысячи. 1 -2 место стабильно с момента запуска. На сайте практически нет контента — все страницы идентичные с текстом "купить бла бла бла".

Ну вполне так и должно быть. Вы мою позицию подтверждаете: домен региона без поддоменов нетрудно двинуть, второе то что генерация контента с умом даёт результат (как многие и делают агрегаторы). Даже не удивлён.

домен региона без поддоменов нетрудно двинуть

Но если регионов много, 100 небольших городов, то проще двинуть каждый поддомен по-отдельности, чем весь сайт без региона. БЕЗ УСИЛИЙ. И поле, о котором Вы отозвались пару страниц назад не в лучшем свете, способно сгенерировать контент так, что каждый поддомен залетит в ТОП. Если не увлекаться, конечно, и продумать. Ну вот, например, экспериментировал пару дней назад, вот что я соорудил этим полем — всё генерируется на основании того, какие значения выбраны в полях (выпадающих списках):


Как раз недавно делал сайт клиенту по шкафам купе, так остались в памяти характеристики, удобные для экспериментов.

У меня регион небольшой — пригород Питера, правда с Питера заказы тоже есть, мне вот как раз про мебель стёкла и прочее надо продвинуться, как мультисайтовость может помочь? Как для меня для фирмы сделать так чтобы по шкафам и прочему быть в топе, скажите для примера
Или это только для крупных компаний работающих в нескольких регионах сразу?

У меня регион небольшой — пригород Питера, правда с Питера заказы тоже есть, мне вот как раз про мебель стёкла и прочее надо продвинуться, как мультисайтовость может помочь?

Никак. Как раз в Вашем случае она не нужна.

И поле, о котором Вы отозвались пару страниц назад не в лучшем свете, способно сгенерировать контент так, что каждый поддомен залетит в ТОП.

Главное не увлекайтесь. Это фишки дорвейные такая жесткая перелинковка, но им то на месяц-два и без разницы что потом.

Главное не увлекайтесь

Я в курсе))

прочитал мельком, трудно читать когда не только требования, а ещё и обсуждение + мнения + споры, а так 2 поста на первой странице по теме вы вообще о разном) шэльдэ бердэ бельдэ, о том что нужен компонент который по сути для какого то типа контента или объектов компонента делает автоматом поддомены, для типов контента (с учётом связи), может от опции какой либо типа (скрытого типа поля, для админа, или там биллинга, хз моё предположение) + ну и доп плюшки всяческие сеошные, я многое опускаю для простоты
.
vikont, о том что должен быть компонент типа поддомены что ли)) или сайты)) где код 1 а бд используются разные, но некоторые общие или хотя бы на уровне бд под поддомены/сайты разные прейфиксы таблиц, или прям по доп колонке в каждом типе вариантов уйма)) в общем разные хотения под общей сути, простите если что напутал)

так вот ранее для ins1 была доработка в который какие либо разделы были на главном домене, какие либо на с учётом поддоменов, так же для мапса, при типе размещения премиум, был так же доступ по урл. с поддоменом, ну а по обычному был редирект, основано было на виджете выбора города, как раз в нём некоторые города имели свой поддомен а некоторые нет, кому интересно в лс могу кинуть урл проекта

позже была проще задача уже на ins2 внутри домена, создавать автоматические поддомены для пользователей вроде тоже успешно, не помню точно 2.5к вроде, могу без админки повторить под вашу тип контента или что ещё

ещё на ларике была задача для магазина самопис, сделать возможность добавления доменов, с единым ядром, но с разными почтовыми настройками, сео переменными, robots.txt файлами, и так же автоматической надбавки к цене с отправкой в amocrm дубля заказа

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

Ideasdigger, не, тут ТС — паровоз, пусть тащит, если хочет и может.)) Ему и ТЗ писать и разработчика выбирать и мозги ему парить. Зато и получать, что заказывал.

Если ТЗ выполняется, то не может быть никаких претензий к разработчику.
И никаких хотелок от участников складчины, отдельно высказываемых разработчику. Один заказчик, один исполнитель. Остальные участники общаются с заказчиком, а не с разработчиком.

В первом посте ТЗ примерно изложено, другие варианты от участников обсуждения — только мысли в слух.
Я готов поддержать любой вариант, в том числе и со сторонним разработчиком.

Мне пока не надо, поэтому своих требований нет. В перспективе, может быть, обращусь к Вам, Ideasdigger, если можно.

за которую вряд ли кто то возьмётся

За складчину я мог бы взяться, а за разработку Fuze, при условии, что соберем нужную сумму. Другое дело, что я не увидел достаточное количество желающих. А из тех, кто проголосовал ЗА, вряд ли все дружно скинутся по 10к.

каждых своих 5 копеек добавит уже с ломающей сутью и в итоге угодить всем не получится

Как правильно выше подметил Asket, ТЗ в первом посте. Единственное, что могу добавить, так это то, что там не примерное ТЗ, а полное на текущий момент. Вся эта тема именно об этом и ни о чем другом. Т.е., опрос о том, нужен ли описанный в первом посте функционал кому-то еще, и готовность участвовать в складчине на разработку именно такого функционала. И, что очень важно, разработчиком должен быть разработчик инстанта, чтобы этот функционал был в коробке, ровно работая вне зависимости от обновлений.

Т.е. обычный сайт будет отличаться от такой сети только ссылками.

А вот как раз это наихудший способ использования мультисайтинга! Такие сайты я еще лет 10 назад делал и назывались они ГС (говносайты)
У каждого сайта должен быть еще свой собственный контент! А мультисайтингом объединяются какие то общие ресурсы!

Например есть единая база документов, а каждый сайт берет оттуда (как бы эта база была на самом сайте) только нужные разделы!

Другой пример: Один большой магазин, а отдельные сайты — специализированные магазины, использующие отдельные виды товары большого. В большом магазине отдели обуви или спортивных товаров, превращаются на отдельных сайтах в магазины обуви и спортивных товаров.При этом не надо ничего встраивать и подгонять под дизайн, так как используется база товаров как своя.Так же надо ничего синхронизировать!

Примеров можно приводить массу! Все они основываются на общем использовании баз данных.

А мультисайтингом объединяются какие то общие ресурсы!
...
Примеров можно приводить массу! Все они основываются на общем использовании баз данных.

Вот об этом я раньше и писал, такое бы я поддержал звонкой монетой.

как раз это

Такое впечатление, что Вы прочитали одно предложение только из всего. То, как Вы дальше описали Ваше видение мультисайтовости, именно так всё и должно работать. Но, чтобы это понять, нужно не выдергивать слова из контекста, а попытаться вникнуть во всё описание целиком. Есть единая база, вся информация может быть выведена на основном сайте. И также есть отделы (поддомены), на которых может быть выведена только та информация, которая относится к данному отделу.

У каждого сайта должен быть еще свой собственный контент!

И это предусмотрено. Разрешить добавлять, например, фотоальбомы только со страницы поддомена, на основном сайте отключить показ списка. Всё! Каждый поддомен имеет свой собственный контент, которого нет больше ни на одном из поддоменов и даже на центральном сайте. Но также есть общая информация, которая может быть на любом сайте из сети.

они основываются на общем использовании баз данных.

Если я правильно Вас понял из самых первых сообщений и этого, Вы предлагаете всё усложнить — у каждого сайта своя файловая система и бд, но все они могут пользоваться еще и общей базой с центрального сайта. Я тоже так раньше думал. Но я предлагаю сделать то же самое, только проще для управления, с более простым кодом. А значит это будет работать быстрее, точнее, стоить дешевле и потребует минимум настроек. Итоговый результат этого варианта практически не будет отличаться от Вашего, но будет проще и доступнее. Соответственно, будет стоить дешевле, его будет проще поддерживать разработчику. А это и стабильность в том числе.

Я недавно переписал всё описание. Прочтите заново, там некоторые моменты были изменены, а некоторые дополнены.

Такое впечатление, что Вы прочитали одно предложение только из всего.

Из всего что я прочитал, а это практически все, явно не звучит то о чем написал! Мы же про ТЗ, а там должно быть четко описано.

Вот об этом я раньше и писал, такое бы я поддержал звонкой монетой.

Вот видите! Мой пост был совершенно не лишний!

Пункты 2 и 3. Внимательно.