1. "это страшно только по первому разу" (с) главное понять принцип того как действовать в конкретной ситуации;
2. купите самую дешёвый VPS на месяц "для опытов" с лицухой на ISP. освойте простейшие приёмы SSH + установку и работу с панелью, там всё совсем не сложно. на старт хватит более чем;
на своихЪ ошибкахЪ (с) +
логика и здравый смысл подсказывают, что страницы сгенерированные пагинацией просто обязаны иметь иметь одинаковые (кроме учёта номера страницы) мета параметры - по сути они куски порезанной на части здоровой простыни.
если же вдруг реально появилась такая необходимость - надо лечить не пагинацию, а архитектуру сайта, на куски режется "кривая простыня"...
генерация урлов - вопрос десятый, проблема "переезда" в 99% случаях вообще решается вне CMS - серверными директивами. вам надо выяснить наличие нужного функционала и стоимость разработки/заточки модулей под свои задачи. на крайняк, при шикарном функционале можно тупо заказать заточку роутера cms под старую модель урлов, если нет резонов её поменять.
чем вам может "не нравится" фича, созданная специально для подобный случаев? не левый костыль от разраба, а легитимное средство решения проблемы изменения урла, встроенное в ядро сервера?
чётко и беспроблемно воспринимается всеми ПСы, поСоны говорили, что иногда даже полезна как показатель дополнительной движухи на сайте.
единственный "тёмное" место - старые ссылки, неоднозначность с передачей веса по ридеректу не в ёё пользу, но опять же есть средствА для продвигаемых страниц - а`ля та же "заморозка" в modx...
переезжал на ModX Revo ;) в котором, кроме остальной кучи вкусных плюшек, для особо проблемных страниц можно просто рУками прописать любой путь полностью ("заморозить" генерацию), а для остальных и новых использовать нормальную автогенерацию ЧПУ подстроенную, если нужно/хочется, под любую старую модель...
только если для разработчика проблеммой не является написание пары строк редиректа в .htassess апача или в конфе nginx
гуглим canonical -> находим щастье...
нужен "накопленный опыт" всё не сложно, но много нюансов, дешевле нанять спеца хотя бы на очевидное. надо "отлавливать блох" оптимизируя код на этой cms или делать ребилд решите когда закроете самые большие и очевидные дырки... хотя если хотите попыться, почему нет ;) для начала гуглите "кэширование статики" потом и "gzip", а можете просто на эту тему хостеру мозги потрепать...
----
опс, у вас там ещё и XSLT приляпан, звери, а не разработчики 😂 совет: закажите аудит у богоносца, он плохому не научит, если соблаговолит, конечно...
вы видимо настоящего говносайта не видели 😂
сначала, хотя бы, включите кэширование статики, а то при каждом клике страницы целиком по новой грузятся (это проще всего и абсолютно необходимо) + на серваке gzip стоит всё же использовать. тогда хоть надолго виснуть будет "только по первому разу". ну а время генерации определяется производительностью и сервака и CMS и что то с этим вам решать придётся. по большому счёту уже порядка 200 ms на генерацию непозволительно много, а тут на секунды счёт идёт...
пардон, но на созданный последним для регистрации у вас почтовый ящик через пару недель после регистрации стали приходить ежедневные потоки спама на тему "продвижения" и только на неё (!) хотя специализация у сайта заманчивая для спаммеров. может это всё и из "хороших рук", но ящик приходится отключать, что бы глаза не мозолил мусором. на другие, созданные намного раньше, таких потоков нет и не было. видимо всё меняется..
а если pindom не врёт (не должен) и больше 60% времени загрузки жрёт генерация страницы, то можно пока и не нанимать. лучше копить деньги на ребилд...
так как повезёт 😂 у меня то 9 то 12 наверное может и 8 а то и 7 выскочит, а может и 15. но генерация (даже если вычесть DNS, синтаксис и остальную лабуду - почти весь жёлтый кусок "wait") просто гомерическая...
---
сейчас стабильно 5-7 показывает, не комильфо, но уже туда-сюда для тяжёлого сайта...
