Друзья. Вы сделали магазин, заполнили товарами 500-1000 штук, отладили дизайн. И тут начали задумываться об оптимизации. Что же можно предпринять в данном случаи не вдаваясь в подробности ?? Все просто, возможно вам просто нужно купить необходимые модули и установить их. 1. Оптимизация базы данных IMDBOptimizer (OC 2.3) - Оптимизация базы данных Данный модуль проведет базовую оптимизацию вашей базы данных. Просто простым нажатие кнопки в модуле вы получите оптимизацию вашей базы данных. Считаю что за 500р. это очень дешево так как специалист при ручной оптимизации возьмет с вас в 10 раз больше!! 2. Микроразметка Микроразметка (application/ld+json / microdata) PRO О да!!! Микроразметка нужна для оптимизации магазина. Возможно в вашем шаблоне уже все есть (реализовано расстановками тегов), но в основном ее нет. Зачем вам нужна данная разметка? Если простыми словами, с помощью нее поисковики правильно понимают ваш сайт. Ведь микроразметка с помощью современного формата ld+json указывает на основные элементы вашего сайта т.е поисковик меньше тратит врем н изучение структуры вашего сайта и тем самым быстрее войдет в индекс с правильными данными. Тем самым и позиции будут выше. 3. Улучшители индексации [SEO] Full IndeX : Улучшение индексации Да да, всегда есть куда стремится. Есть что улучшить. Закрыв глаза и не вникая мы можем улучшить индексацию простым способом, а именно применив выше указанное решение. Модуль помогает улучшить индексацию, более продуктивно "прокачать" товары и решить проблему дублирования страниц постраничной навигации, что позволяет поднять в выдаче НЧ-запросы страниц товаров расположенных на удаленных страницах. Управлять множеством факторов и решает ряд недочетов в Opencart. 4. Модули для быстрого старта IMFastStartPack (OC 2.3) - Пакет модулей для быстрого старта вашего сайта Быстрый старт магазина и сео оптимизация - возможна! Как раз данный пакет модулей поможет вам провести еще одну базовую оптимизацию, а именно Уникализация текстов продуктов и статей (SEO оптимизация) Перелинковка товара (СЕО) Финансовый анализ и контроль (расширенная отчетность) Форма обратной связи Вот так вот просто, 4 модуля в одном, но очень нужные!! 5. Карта сайта FX Sitemap 2.0 - Скоростная карта А куда без карты сайта? Ведь поисковик смотрит в нее тоже и если она "плохая" то и соответвенно индексация будет на том же уровне. Встроенная карта сайта конечно рабочая, но не идеальная. Работает медленно, нет возможности выгрузить в файл и не все ссылки попадают в карту. Вот выше указанное решение и исправит все недостатки стандартной карты.
Самый большой вопрос Это к первому 1. Оптимизация базы данных Пока не увижу что внутри никому советовать не буду Пока не увижу результаті работы - никому советовать не буду По описанию, по демо - ну добавляет индексы, ну позволяет как-то управлять добавлением индексов ну.. делает optimize и analyze С одной стороны - индексы лишними не бывают, С другой - ох как бывают, а причина в оптимизаторе, если он посчитает что этот "плохой" индекс лучше всего подходит.. Поясню на простейшем примере У вас есть таблица на 1000 записей (цифра от фонаря), и в таблице 100 уникальных индексов (составной), например id+value И вам нужно сделать выборку Если оптимизатор предпочтет индекс, то он будет, условно, менять указатель по записям, 1, 20, 100, 50, 40, 999 и т.д - физически - двигать головку Но можно тупо сделать последовательный fullscan (полное сканирование) и это будет на проядок быстрее. Надеюсь пояснил
Второе Перелинковка товара (СЕО) Это очень больной вопрос в СЕО, неудачной перелинковкой можно угробить сайт Перелинковкой должен заниматься ЧЕЛОВЕК, а на автомат, автомат может только подсказать тонкие места, а анализировать необходимость - только ЧЕЛОВЕК
Скептицизм - вещь хорошая, не спорю. Поэтому приведу хотя бы пару моментов Во-первых. Модуль появился не сразу и вообще был сделан на основе моего модуля для Joomla, который хорошо себя зарекомендовал. Дело было примерно так. Писал статьи на свой сайт. Потом обратил внимание, что достаточно много статей вообще не в индексе (причем долгое время не входили). Стал изучать вопрос. Уткнулся в то, что грамотная перелинковка - очень полезная вещь (штудировал сайты и форумы по сео). Одной из наиболее подходящей схемой для большого количества страниц оказалась кольцевая перелинковка. Немного подумал, почитал про вес, ссылки и прочее, а затем улучшил механизм до множественной кольцевой перелинковки. Внедрил к себе на сайт. Спустя месяц, абсолютно все статьи вошли в индекс. Потом внедрял подобное на другие сайты. В одном из комментариев к исходному модулю можете увидеть, что человек, которому допиливал, не поленился и проверил общий вес сайта (после внедрения он возрос вдвое у него). Соответственно, когда стал делать модули под опенкарт - решил что вещь будет очень полезной и для магазинов (суть-то во многом схожа, хоть и есть отличия по продвижению). Во-вторых. Многие магазины вообще не имеют перелинковки в товарах. Ну и представить себе, как человек вручную составляет список для 1000-2000 товаров. Это не считая побочных плюсов, например, от вообще наличия других товаров в карточке.
Сразу. Ну, вообще при 1000 записей и 100 уников (не обязательно, что индекс должен быть составной - просто неуникальный) - среднее количество записей будет примерно: 7 проверок по индексу до узла дерева + 10 чтений записей (10 против 1000 как-то разница есть, особенно при условии, что в ряде таблиц записи это просто монстры из полей, так же при join с другими таблицами идет умножение и там это разница особенно скажется - там же умножение). По поводу "увижу". Вполне понятная логика - не вы один такой (со всеми вытекающими). Однако, модуль и его базовую оптимизацию писал исходя из двух вещей: 1) В инете есть примеры базовой оптимизации - они и были взяты за основу. Причем вы и сами можете их найти (однако выполнить их может только тот, кто в этом разбирается - у остальных явно проблемы будут) . И там народ отзывается положительно. 2) Очень многих индексов для вторичных ключей попросту нет. Причем даже в нагрузочных таблицах (на лайве статья все еще не опубликована, поэтому не буду лишать удовольствия). А ведь это базовые основы - любой вторичный ключ должен иметь индекс. Может в сверх нагруженных проектах, таким и можно пренебречь, но это ведь интернет-магазины малого бизнеса и у них не такие нагрузки. Остальное в модуле делалось для удобства автоматизации, исходя из ваших практик. То есть к примеру, убедитесь в том, что нужно достраивать ряд ключей по умолчанию, то вот есть удобный инструмент, которому лишь нужно их перечислить, все остальное он берет на себя. По поводу оптимизатора. При базовой оптимизации, как уже говорил, достраиваются лишь вторичные ключи + ключи из существующих опробованных и подтвержденных практик другими людьми. Соответственно, когда речь заходит о вторичных ключах, то они в любом случае являются первым полем в составном ключе. И мало вероятно, что при наличии уточняющих условий по прочим полям из составного индекса, оптимизатор решит воспользоваться вторичным ключом (даже если такое и случится, то все равно разница между полным сканированием и индексом будет). Про подтвержденные варианты - там либо составные индексы с участием вторичных, либо поля, к которым вообще индексов нет или их наличие необходимо проверить (например, для oc_settings поля с code для более быстрого чтения).
А давайте в другую тему.. 1. В ОС есть достаточно модулей, чтобы сделать перелинковку, даже встроенных последние, рекомендуемые, сопутствующие, бестселлеры и прочее Или автоматические рекомендуемые, предыдущий/ следующий, и прочие И чем это не перелинковка? Также и со статьями.. можно поступить, и не надо никаких хитрых перелинковок придумывать.. Я понимаю, что такое вес, но я повторю, что при продвижении, так же нужно понимать что двигаем, чему поднимаем вес, какая у нас "посадочная" страница. а не просто поднятие веса. Многие магазины, действительно не имеют.. возможно.. а на самом деле имееют, опосредовано Категория - товар - производитель - товар Еще проблема в том, что закрывая отитндексации страницы пагинации, тем самым грохают товары на страницах с пагинацией. Вот тут возможно и нужны всякие перелинковки Кроме того есть еще и теги (но и их закрывают) Т.е. это мое мнение. А выход - самый простой noindex, follow - все счастливы, все довольны
Извините - бред. Не нужно быстрое чтение. Да, я как-то столкнулся, что SELECT * FROM setting был чуть ли не самым тормознутым запросом, как оказалось - это что я писал - оптимизатор выбрал не тот index потому что какой-то умник проставил индексы. таблица oc_settings читается вся и сразу, только отдельные модули, в основном, левые, стучатся туда.. Таблица предназначена для хранения статических настроек, а не для оперативного хранения данных
Еще раз говорю, перелинковка перелинковке рознь. Бестессеры - перенос веса в одну часть сайта, при этом прочие страницы остаются без дополнительного веса и как следствие больше шансов для выхода из индекса. Сопутствующие (рекомендуемые) - это та таблица, которая как раз руками заполняется. Автоматически рекомендуемые - это вообще отдельный модуль. Но, его перелинковка хаотична, ее нельзя оценить. Часть страниц будут с большим весом, часть с меньшим (то есть перекос). Плюс еще раз говорю, что делал на основе своего опыта и опыта с сео форумов. А в сео все либо эксперементы, либо догадки. Поэтому тут можно спорить бесконечно. Посадочные страницы не оформляются модулем за 600 рублей, а всегда делаются вручную, плюс им нужны контекстные внутренние ссылки, а не ссылки из блоков. Категория - товар - производитель - товар. - Это стандартная схема, она дает лишь минимум. Например, минусы - страница пустая. Проблемы с категориями или производителями - автоматом существенно влияют на отдельные страницы товара. По поводу noindex, nofollow - тут вообще надо быть очень аккуратным. Кроме того, гугл так вообще даже robots.txt легко может игнорировать, так что.
Открываем модель settings и видим: class ModelSettingSetting extends Model { public function getSetting($code, $store_id = 0) { $setting_data = array(); $query = $this->db->query("SELECT * FROM " . DB_PREFIX . "setting WHERE store_id = '" . (int)$store_id . "' AND `code` = '" . $this->db->escape($code) . "'"); foreach ($query->rows as $result) { if (!$result['serialized']) { $setting_data[$result['key']] = $result['value']; } else { $setting_data[$result['key']] = json_decode($result['value'], true); } } re
Не знаю, откуда у вас такие сведения.. мой бот чекер ни разу не показал захода ПС (Г и Я) на страницы закрытые роботсом. Причем здесь пустая страница категорий? Кто на нее ссылается? только из меню А товар туда ссылаться не будет, ибо его там нет А ну-ка в чем и где должна быть аккуратность? Что у вас на этой странице может быть такое?
Не смешите, потрудитесь посмотреть кто вызывает этот метод.. Код: $from = $this->model_setting_setting->getSettingValue('config_email', $order_info['store_id']); Только в одном!!!! контроллере!!! А для админки.. Сама админка не требует спешки.. И.. мое мнение, не фик там оптимизировать
Посмотрите индекс страниц по моему демо сайту http://oc2102rs.im-cloud.ru/robots.txt Там в роботс все запрещено, а гугл индексирует. Почитайте про перелинковку, вы путаетесь. Я же сказал, что это стандартная перелинковка со своими минусами. И ее в сегодняшних реалиях недостаточно. По поводу индекса и фоллоу. Я просто говорю о том, что этому вопросу нужно уделять немало времени.
Так вы уже противоречите своим словам о том, что считывается только один раз и вся таблица. Плюс точно такой же метод в каталоге. И многие модули хранят настройки в сеттингах.
Индексирует или находится в индексе https://www.google.com.ua/search?cl.......0...1.1.64.psy-ab..0.0.0....0.98Zfy1ehWhU Вот закрыто.. Вы посмотрел в каком контроллере идет вызов, и как часто такие запросы вополняются? Оперативный ли это запрос? А читается эта таблица в startup
какими любыми? Я вам показываю, бессмысленность вашего решения.. Правоту? Да я рад бы ошибиться, и принимаю конструктивно критику, и признаю не состоятельность. Но от вас пока не последовало ничего ни про перелинковку, ни про оптимизацию, кроме как слов - индексы должны быть и перелинковке - место
Для тех, кто будет читать ветку: В описании модуля IMDBOptimizer есть ссылка на статью, где я проводил тестирование при 2000 и 5500 тысячах товаров.
МУЖИКИ, НАШЁЛ РЕШЕНИЕ! Если сайт долго загружается из-за большого количества товаров, нужно добавить следующий индекс в Базу данных : ALTER TABLE `oc_category_path` ADD INDEX ( `path_id` );
Вы заблуждаетесь. И мало того, кто то может решить, что такой запрос все поправит в их печальной ситуации и не получив результатов, придет вопрошать к вам о подробностях. Это один из большого количества запросов, для добавления индексов в таблицы базы данных опенкарт. И для всего этого есть прекрасное решение, от очень уважаемого мной автора https://www.opencart.com/index.php?...y_id=8&filter_license=0&filter_download_id=35 При чем и это не панацея. А лишь часть общей работы по оптимизации.
