Существуют ли какие-либо недостатки и/или риски при использовании метаданных в строке запроса?
У меня есть страница поиска для наших сайтов, которая выполняет поиск в зависимости от значений следующих параметров в строке запроса;
q: строка поиска cats: строка, разделенная запятыми, соответствует продуктам, принадлежащим нескольким категориям tags: строка, разделенная запятыми, соответствует продуктам, имеющим определенные теги
Теперь я планирую включить метаданные и ключевые слова OG в строку запроса для целей рекламы на Facebook. Например, чтобы иметь OG источник изображения, заголовок OG и описание OG в строке запроса позволят мне настроить одну страницу (результаты поиска) в зависимости от моих требований.
Например, если бы я хотел рекламировать молочные продукты, мой URL-адрес был бы следующим (не закодирован для краткости здесь):
results/tags=milk,cheese,yoghurt&ogimage=img/social/dairy-cover.png&ogtitle=Some Title&ogdesc=some description
Аналогичным образом я бы использовал следующее для уборки дома;
results/cats=home-cleaning&ogimage=img/social/house-cleaning.png&ogtitle=Cleaning products&ogdesc=some more description
Я также намерен расширить этот подход, включив в него другие части строки запроса, чтобы у меня также могло быть другое содержимое на странице. Например, Если Я также хотите включить карусель связанных товаров после результатов поиска;
results/{same-as-above}&carouselId=3
Что я хочу выяснить, если;
- этот подход является хорошей или плохой практикой, поскольку любой может изменить строку запроса.
- если у него есть какие-либо недостатки с точки зрения SEO
- У меня должны быть проблемы с индексацией в поисковых системах из-за того, что я обслуживаю одну строку запроса, отличную от страницы
- если есть какие-либо проблемы с безопасностью, я должен быть в курсе.
- Любые другие соображения, на которые мне нужно взглянуть.
Заранее благодарю
2 answers
То, что вы, похоже, эффективно делаете, - это создаете своего рода страницу архива, на которой вы планируете перечислять различные типы продуктов. Страница категории.
Более разумным подходом было бы реализовать более привлекательные маршруты, такие как /категория/уборка дома, /метка/молоко.
Затем вы можете создать отдельный список категорий и список страниц тегов в своей карте сайта. К этому также могут быть добавлены ваши пользовательские теги OG и дополнительные сценарии для отслеживания просмотров категорий.
Этот подход является хорошей или плохой практикой, поскольку любой может изменить строку запроса.
Да, это было бы моей главной заботой... "любой" (читай: любой злоумышленник или бот ) может манипулировать URL-адресом и изменять содержимое страницы. Бот может заменить любые вредоносные ключевые слова в параметрах ogtitle и ogdesc и заполнить ваш сайт тысячами нежелательных URL-адресов (тратящих ресурсы сервера), которые потенциально могут быть проиндексированы (хотя см. Следующую часть ниже) и тогда у вас есть очень реальная проблема.
Я не понимаю, почему данные OG должны быть включены в URL-адрес? Вы, вероятно, знаете данные OG, чтобы в первую очередь сгенерировать URL-адрес? В этом случае это, по-видимому, следует "искать" на основе известных тегов . (?)
Если у него есть какие-либо недостатки с точки зрения SEO
Если вы разрешаете индексировать эти URL-адреса, то это проблема для SEO.
Однако результаты поиска по сайту не должны быть индексируется поисковыми системами. Google не хочет индексировать ваши результаты поиска, он хочет индексировать ваши страницы.
Итак, предполагая, что вы следуете рекомендациям и не разрешаете индексировать эти URL-адреса, "SEO" не является проблемой.
У меня должны быть проблемы с индексацией в поисковых системах из-за того, что я обслуживаю одну строку запроса, отличную от страницы
Опять же, страницы результатов поиска в первую очередь не должны индексироваться поисковыми системами.
Строго говоря, разные строки запроса создают разные URL-адреса и, следовательно, разные "страницы". Тот факт, что у вас есть одна конечная точка, которая обрабатывает этот URL-адрес, в основном не имеет значения.
Если есть какие-либо проблемы с безопасностью, я должен быть в курсе.
Потенциальное "злоупотребление", как упоминалось выше.
Любые другие соображения, на которые мне нужно взглянуть.
Излишне длинный URL-адрес, который может быть неизбежно "разделен" при совместном использовании и потенциально создать недопустимые URL-адреса.