Includere id produs in url-uri?

Salut,

Bine v-am gasit!
Pentru un site in php cu foarte multe produse (peste 100k) vreau sa setez url-urile tip produs.
slug = numele produsului, meta title al paginii
id = id_produs din db
M-am gandit la urmatoarele 3 variante:
a)slug
b)slug-id
c)id/slug

In varianta a) in db se cauta dupa campul slug, care este varchar si are index.
In variantele b) si c) in db se cauta dupa id-ul produsului.

Varianta a) ar fi ideala, dar ma gandesc ca variantele b) si c) ar fi mai bune ca si performanta/rapiditate.

Credeti ca ar fi o diferenta semnificativa sau nu ar conta?
Ce varianta ati alege si de ce?

Multumesc anticipat pentru raspunsuri.

1 Like

a) slug-ul se mai schimbă, și vei ajunge să salvezi super multe versiuni mai vechi pentru a redirecționa

Între b) și c) aș alege b) pentru că id/slug sugerează că id/ e director (ar trebui să aibe index și să mai fie și alte pagini acolo (de exemplu id/altceva).

b) și c) câștigă clar din punct de vedere al performanței.

ideal dpdv seo+ux e doar slug cu minusurile aferente (performanta, duplicate check, redirectari)
eu merg pe varianta /slug-id.html
dpdv seo e bine sa nu ai id sub forma de folder pt ca nu ajuta la ierarhizarea a informatiei iar performanta (daca vorbim de milioane de rows) mai degraba dupa un integer

Multumesc pentru raspunsuri.

Pe langa varinta b), care se pare ca e cea mai ok dintre primele 3, mai este si o a 4-a varianta d) slug/id cum sunt si url-urile devforum.

Credeti ca url tip slug/id ar influenta negativ dpdv seo? Personal nu vad de ce si ar fi cel mai usor de implementat.

Cuvintele mai aproape de rădăcină au un scor mai bun, așa că eu aș muta id-ul către coadă, fie în versiunea slug-id sau slug/id. Pentru că “-” e separator în slug, prefer ultima varianta - slug/id.
Nu văd rostul lui “.html”?

1 Like

Niciodata sa nu expui id-urile din baza de date, genereaza un slug compus din numele produsului in care inlocuiesti " " cu “-” si adaugi un string random, la sfarsit. Mai bine de atat ar fi ca din numele produsului sa elimi “stop words” atunci cand generezi slug-ul.

1 Like

Care ar fi motivul?

In functie de baza de date si ce expui tu pe linkurile alea le lasi celor care acceseaza resursele sa ghiceasca baza de date, numarul de produse, numarul de vanzari, etc. Dai niste informatii care ar fi mai bine sa fie secrete. E o regula generala asta cu id-urile.

Nu cred ca ar fi o problema grava, atat timp cat id-ul apare doar la produs si nu la user. Nu e magazin online, deci nu sunt informatii secrete. Am vazut site-uri mari care expun id-ul fara nici o problema.

  • Pe de alta parte, ca sa nu expun id-ul, mergand pe ideea ta (multumesc), am ales sa generez un sir random, de 9 caractere, pe care sa il atasez la urma, iar url-ul va fi de forma ex slug/secret_key
    Exact cum are si emag-ul.
    E o varianta buna dpdv seo, deoarece daca schimb slug-ul sau tastez ceva gresit in slug, fac automat 301 redirect catre url-ul corect, pe baza secret_key.
  • Din punct de vedere al performantei in mysql, cautarea in varianta cu cheie unica pe sirul random, presupun ca e o varianta de mijloc intre cautarea dupa id numeric si cea dupa slug.

Ce regulă e asta de nu o respectă nici Google, nici Facebook, nici… doar la niște indieni am văzut așa ceva. Cum generezi tu id-urile, e altă poveste - nu e musai să folosești autoincrement.

Uite un id de pagină fb: 578846169290290. Vezi dacă poți face ceva cu el! Dau o bere.

El se referea la id-urile cu autoincrement. Alea pot da informatii despre dimensiunile bazei de date. Daca folosesti uuid-uri/guid-uri nu ai problema asta.

Dar pot să apară alte probleme. De ex., la facturi, declari niște plaje la început de an și apoi ce ai folosit din plajele alea; dacă ești firmă mică, nu interesează pe nimeni baza ta de date, iar dacă ești firmă mare sunt atâtea raportări și posibilități de a obține informațiile încât artificiul cu id-urile e practic inutil. Rare sunt cazurile în care chiar e nevoie de așa ceva, iar alea reprezintă mai curând excepție decât regulă.

În vremurile pe care le trăim, ascunderea informațiilor nu mai constituie un avantaj competitiv. Metro și Selgros, de când sunt pe piața din Ro, au ascuns intotdeauna informațiile despre preț - e o adevărată provocare pentru angajații lor să ia prețurile de la concurență. Pe segmentul non-food, când tu ai prețurile doar în magazin sau trebuie să sune clientul la un număr la care nu răspunde nimeni, poți concura cu magazinele on-line? Eu zic că nu.