Требуется платный cms агрегатора

тебе нужен молл. в частности ecmoll или brand.

И дорога тебе сюда one-st.ru

тут занимаются адаптацией китайских скриптов

Мы чем-то подобным занимаемся. Делаем моллы, площадки, где много продавцов и у каждого свой магазин. Изначально делали каталоги с поиском блюд для ресторанов одного города. Но сейчас тематики разные: подарки, мебель, услуги.

Разница в том, что у ресторанных каталогов не было страницы отдельного товара. Там пользователь не должен залазить в меню дальше списка блюд одного вида (пицца, суши, салаты и т.д.). В подарках и мебели можно иметь отдельную страницу под каждый товар.

Суть одна: система поиска товаров по фильтрам или словам в названии и описании. В системе присутствуют множество продавцов, каждый имеет 1 или несколько магазинов, сам управляет описаниями товаров, мета-тэгами (title, descroption, keywords, заголовок Н1 на данной странице), текстовыми страницами в рамках своего магазина.

Для себя делали вот это и это, еще раньше - агрегатор доставки пиццы для Москвы. Примерно, с дюжину проектов уже поставили или допиливаем под конкретного заказчика.

Можно делать с разбивкой на регионы. Каждый регион может находится на своем домене или субдомене. Сейчас разрабатываем каталог кейтеринговых компаний: доставка обедов в офисы, организация корпоративов для Уфы, с последующим охватам 20 городов, Екатеринбург, Москва ну и так далее по карте России (Приведенный пример в стадии разработки).

Уфа - name.ru

Москва - msk.name.ru

Екатеринбург - ekb.name.ru и так далее.

Для SEO в каждом городе или регионе свои настройки мета-тэгов для разных групп страниц, свои Яндекс.Вэбмастер, Метрика, Google.Analytics, могут быть свои группы в соцсетях и т.д. Это все настраивается не вэбмастером, а любой секретаршей через админку. Правда, это все надо заполнять.

Есть для ленивых встроенный конструктор метатэгов, но круче все ручками писать, ибо пока он склонять не умеет, он напишет "доставка.суши.Минск", но не напишет "доставка суши в Минске", если надо сгенерировать еще 500 метатэгов с разными товарами и городами. Думаем, но пока не научили его падежам и склонениям.

Администрирование предусматривает 3 роли:

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

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

- Администратор магазина (управляет одним или несколькими магазинами, добавляет разделы меню или группы товаров, добавляет и меняет описания товаров, картинки, цены). Эта рооль дается хозяину магазина и нашему эккаунт-менеджеру (курирует от 20 магазинов).

Технически, на базе нашего движка можно развернуть каталог товаров типа рынка электроники на белорусском Онлайнере. Можно и что-то типа alibaba.com запустить, но как-то не пробовали пока, повода не было.

Думаю, на Drupal это реализуемо, но естественно потребуется найти хорошего разработчика, готового взяться за дело.

Интересно

Как оформляется заказ, если в корзине у покупателя товары от разных продавцов?

У каждого Продавца свои способы и регионы доставки?

Оплата за товар поступает на счет Продавца? У каждого Продавца подключены индивидуальные платежные системы?

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

Технически нет проблемы сделать 1 корзину, куда складываются товары от множества продавцов.

Просто, в ресторанных проектах эта схема вредна, он не стыкуется с их реальной логистикой. Никто не будет собирать в одну машину еду из разных ресторанов. Даже в Минске между ними 20-30 километров расстояния есть, могут быть пробки, перекрытые улицы. А счёт идёт на минуты - еда стынет, голодный клиент ждёт, нервничает иногда.

- да, у каждого свои. На белорусских сайтах этого не видно, т.к. Минск - относительно небольшой город.

Но изначально движок делался под Москву и Питер. Там каждый ресторан доставляет на жестко оговоренные станции метро и в определенные районы. Т.е. один город может быть одновременно разделен на несколько типов зон доставки (станция метро, административный округ, микрорайон, для Германии - почтовый округ, т.е. все дома с одним почтовым индексом).

Изначально делали даже какую-то геолокацию - клиент вводил адрес или ближайшую станцию метро - ему выдавались все службы доставки в радиусе 20 км, которые ближе - шли первыми. Все это работало на основе привязки к Яндекс.Картам и Google.Maps. Но активного применения этому инструменту почему-то не нашли, так и остались только в тестовой версии у нас.

Вокруг нарезки города на зоны доставки, отчасти, планировали строить и SEO таких проектов в Москве. Движок способен генерировать страницы для реального пользователя под множество низкочастотных запросов: "доставка пиццы измайлово", "доставка суши измайлово" и т.д. Часть метатэгов может заполнятся автоматически, конструктором. По ним несколько реальнее привлечь траффик для молодого сайта, чем под ВЧ-запросы, охватывающие всю Москву.

Можно подключить как оплату на счёт агрегатора, хозяина молла, так и каждому ресторану (магазину) отдельно. Технических препятствий тут нет. Но этого нет в типовом движке - надо делать для конкретного проекта индивидуально. Я пока не видел 2 совершенно одинаковых проектов.

И надо юридические формальности уладить с платежной системой или банком-эквайером. Они обычно требуют, что на сайте было чётко видно, кому именно клиент платит деньги. И договор на обработку платежей должен быть заключен именно от имени этого юридического лица или ИП.