Так почему у вас до сих пор нет магазина? :)
Я предпочитаю белую :)
Ну, сами подумайте логически: ну, откуда некий представитель может знать, как на самом деле работают алгоритмы, механизм работы которых хранится в строжайшей тайне? Откуда ему знать, как там что влияет или не влияет на самом деле?
Является ли протокол https фактором ранжирования? Конечно является. А вот в какую сторону он действует - в плюс или минус - зависит от конкреного сайта, конкретного поведения пользователей и окружения. В условиях, когда в алгоритмах применяются нейронные сети, вам и сами разработчики не скажут точно, как и почему повляет/повлиял тот или иной фактор. По той простой причине, что результат зависит от модели из тысяч факторов, от их конкретной комбинации. И поэтому сейчас глупо гадать, что какой то фактор работает в плюc, а какой то в минус.---------- Добавлено 27.04.2017 в 23:46 ----------
Зачем? Какой смысл?
-------------------------------
Типа того. Не диплом, но суть такая. Длинный текст разбивается на структуру - на связанные между собой кусочки.
ale5, Я с инетмагазинами плотно не работаю, но смотрел демки некоторых коробочных движков, поэтому если ниже буду не прав, пусть меня спецы поправят.
Вы вот считаете вашу задачу простейшей. Я глянул ваш файл для импорта и с ходу вижу несколько нетривиальных вещей. Например, кроме производителя товара имеется еще серия (линейка, модельный ряд) товара. Серии привязываются к производителям. По хорошему счету надо производителей структурировать - привязывать к каждому производителю серии, а товары надо привязывать к сериям. В любом случае при выборе производителя выбор серии должен быть ограничен сериями выбранного производителя. Как вы это мыслите реализовывать? В демоверсиях простых магазинов, которые я смотрел, там просто есть список категорий и список производителей. Механизма создания сложных структур я там не видел. В Друпале это достаточно просто можно реализовать, в фреймворке вообще без проблем. Но... опять таки, возвращаясь например, к друпалу... Да, там тысячи модулей на любой вкус, но практически со всеми возникают какие то проблемы: ошибки после обновлений, конфликты, несовместимости, большинство модулей в альфа и бета-версиях. Короче, просто "взять и установить готовые модули" не получится.
Далее, поле "подходит к...", как я понимаю, содержит информацию в свободной форме, поэтому надежное создание связей - тоже нетривиальная задачка. Плюс в прайсе могут быть ошибки и опечатки. Как их обрабатывать? Как производить откат? Как вести контроль за импортированными данными, чтобы вовремя обнаружить грубые ошибки? Надо создавать систему тестов? Как вести контроль за целостностью структуры, за связями и т.д. и т.п? Короче, там на каждый чих возникает множество вопросов. Как говорится: просто было на бумаге, да забыли про овраги.
Подскажите, а если продавец владел квартирой более 5 лет, ему даже нулевую декларацию подавать не надо, т.е. вообще ничего не надо делать?
FAQs, в большинстве случаев лучше короткий УРЛ и не зависящий от пути категорий. И дело даже не в СЕО (у первого варианта тоже есть весомые плюсы), а в сложностях перемещения страницы из одной категории в другую категорию. И проблема не столько в возможных дублях (это решаемо), сколько в том, что при перемещении страница по старому УРЛу будет выдавать 404-ю ошибку.
Но бывают случаи, когда сам по себе объект не имеет гарантированно уникальной адресации, уникальная адресация возможна только совместно с категориями. В этом случае наверно лучше и проще использовать первый вариант, не смотря на недостатки.
Спасибо за подсказки. Рассматриваю все варианты.
Объединять кусочки в один кусок побольше и в рамках получившейся страницы делать локальную навигацию - это первое решение, приходящее в голову, но... оно нетривиальное в плане реализации, ведь всё будет происходить в полностью автоматическом режиме.
Важность каждого кусочка не всегда просто автоматически точно определить.
Но самое главное, каждый кусочек, даже маленький, является функциональной и в общем то самостоятельной единицей, которая может участвовать в связях с другими единицами, может обрасти некоторой метаинформацией и т.д. Это же сервис по сути будет. А такое искусственное огрубление внешней детализации при сохранении внутренней (логической), боюсь, приведет к излишнему усложнению и запутанности.
Рассматриваю пока такой вариант: те элементы, которые по формальным признакам будут иметь плохой заголовок (это в моем случае можно примерно автоматом вычислять - дублирующие, очень короткие и т.д.), то у таких страниц будет автоматом проставляться метатэг noindex. По крайней мере, это имхо самый простой вариант, не требующий представлять структуру в разных видах (с разной степенью детализации).
Статья по ссылке какая то противоречивая. Если убрать из статьи Адсенс, то тогда всё в статье выглядит логично: информация о банковских зарубежных счетах, принадлежащих россиянам, может начать поступать нашей налоговой в 2018-м году. Россияне с недавнего времени должны отчитываться о своих зарубежных счетах и у налоговой появится способ это проверить. Но при чем тут Адсенс? Скорей всего автор далек от понимания, что такое Адсенс и как всё это работает в России. Единственный вариант, который вписывается в логику статьи - это когда россиянин работает с Адсенсом целиком в иностранной юрисдикции и получает приличный доход на счет в иностранном банке в другой стране. Возможно, наша налоговая получит возможность узнавать о таких счетах наших физиков от зарубежных банков. А что касается доходов от адсенса, получаемых россиянами в России, то налоговая всегда имела и сейчас имеет возможность всё проверить.
Я тоже к этому склоняюсь. Сначала думал всё идеально заточить под поисковики и хотел отказаться от детальной структуры, но... гляжу на результат и понимаю, что подробная структура получается архиудобной - всё лежит как на ладони, что посетителям съэкономит массу времени.
