Nu știu programare, de aia întreb: cum se întâmplă asta?

Am văzut asta de câteva ori pe ȘtirilePROTV.ro: știrea apare în feedul rss, apare pe site la căutare, dar când dai click pe ea e not found. Apare mai târziu, dar bănuiesc că în urma unei intervenții manuale. Așa că sunt curios, de ce apare la căutare dacă ea nu e pe site? Dacă e într-un backend care nu e public, de ce apare la căutare?

ps: știu că știrea a apărut între timp…

Mulțumesc că ai citit acest articol.
Dacă vrei să susții acest blog, cumpără un abonament de 5$

26 comentarii

  1. “There are only two hard things in Computer Science: cache invalidation and naming things.”

    00
  2. Poate se actualizeaza mai repede cautarea (daca folosesc un motor dedicat).

    Sau poate initial apare stirea ok in cautare si in site. Doar ca ulterior modifica ceva in titlul sau url-ul stirii, iar actualizarea nu se face si in cautare. Si probabil ca nu au sistem de redirect (301) automat de la link vechi la link nou.

    Depinde de cum gestioneaza backend vs frontend vs cautare, cum sunt ele sincronizate. Poti doar presupune fara sa stii detalii.

    00
    • S-ar putea ca VOC sa aiba dreptate. Sa fie chestiune de cache care ramane in urma.

      00
    • @Radu: Totusi, nu ar trebui ca atunci cand se actualizeaza un articol, sa trimita un update si la sistemul de caching?

      00
    • @Mihail ar trebui :). O problema este acolo, developerii ar cam trebui s-o dibuiasca.

      00
    • Cum zice Radu, bănuiesc că se folosesc 2 sisteme separate pentru search si afișare. Nu ai de unde sa știi exact ce se întâmplă, dar e posibil ca indexarea soluției de search si actualizarea feedului de rss (care e lucru cu text până la urmă) sa fie gata înaintea publicării efective a stirii (care poate însemna ceva copieri de video, poze sau alte fișiere)

      00
    • Si eu sunt de aceeasi parere cu Radu. Cred ca folosesc ElasticSearch si nu in urma unui update nu au actualizat si titlul. Dar aici intervine alta intrebare: „ok, ok, schimbam titlul articolului si URL-ul lui dar 301 nu implementam ?”

      00
    • Voi vorbiti de ElasticSearch cand aia nici la paginare nu au stiut sa puna niste conditii ca sa nu fie afisata decat atunci cand ai nevoie de ea…

      00
  3. adblocker?

    00
  4. Ei au JavaScript-ul pe site exact cum îl avea omul care a lucrat la el în editor: cu comentarii, cu cod comentat, unminified. Semn că nu se fac prea multe review-uri pe cod și că nici nu au vreun tool să facă ceva automat când să se ducă spre producție.

    Asta ca să știm la ce nivel e site-ul și modul de lucru, ca să nu avem așteptări prea mari.

    00
    • Ai fi surprins daca ti-as spune ca asta e nivelul prin tara? Am vazut site-uri facute pt minister care sunt si mai varza (la fel JS original + tinut credentiale in cod).

      00
    • LOL ! Dai exemplu siteuri facute pentru minister, de parca aia sunt vreun centru de excelenta, Daca ziceai ca sunt siteuri facute pentru clienti pretentiosi, altfel suna. Siteurile alea pentru ministere sunt facute de firme de „casa” pentru spalare de bani, nu pentru a fi facute bine.

      00
  5. Mocanu ce zice?

    00
  6. @zoso: Mai stii cand scriai „dezapezi”? Asa e si-n programare (sau orice altceva), unii sunt caposi, stiu ei mai bine.

    00
  7. Hai sa-mi dau cu parerea si eu. Posibil sa aiba un „publish date” care sa fie in viitor.
    Doar ca nu tin cont de el la RSS si/sau cautare. Dar cand vrei sa vezi stirea, il verifica si primesti not found.
    Incepatori :)

    00
  8. Eu tiu te ale. E……ticat tot. (All this during nose picking) :)))

    00
  9. Mai mult ca sigur au ceva sistem de cache mai idiot si asta isi face refresh dupa x perioada, daca articolul a fost postat dar cache-ul inca nu a fost actualizat, iti da 404.

    00
  10. In termeni populari, se poate explica asa: atunci cand incepe furtuna si norii se ciocnesc, prima se vede fulgeru si apoi se aude tunetu. Cautarea ‘elastica’ indexeaza repede o referinta la nou continut, cum ar fi un titlu bomastic, dar continutul efectiv e lenes (de obicei din cauze legate de dimensiune sau preprocesare automata) sa ajunga pe servitorul de continut. Si ca in orice competitie click bite, conteaza cine posteaza primul o referinta la stire noua, pentru ca aritmetica simpla conteaza pentru google ads de ex, si conteaza mai putin cine o si vizualizeaza primul. Zic si eu … nu sunt specialist

    00
  11. Din afara te gandesti ca backendul e o singura chestie, dar de fapt e o increngatura de multe sisteme care daca nu-s gandite bine dau rateuri la sincronizare. Ce anume numai ei stiu – vezi parerile celorlalti. Am intalnit multe ciudatenii asa ca nu-mi mai dau cu parerea :).

    De asta la interviuri cel putin un subiect e mereu o problema de concurenta/sincronizare.

    00
  12. E ce a zis Mihai mai sus, cel mai probabil folosesc doua db-uri, unul pentru continut si elasticsearch pentru cautari. Pe scurt elasticsearch indexeaza doar titlul si eventual primul paragraf pentru cautari dar continul efectiv e in alt db iar schimbarile se propaga mai greu. Am vazut cazuri in care era nevoie de ore ca sa se propage niste schimbari in db, clar o arhitectura de kkat desi era vorba de un foarte mare retailer.

    00
  13. Posibil sa aibe aprobare pe articol. Tu nu ai drepturi sa il vezi pana nu e publicat. RSS si cautarea il vad pentru ca exista si au drepturi mai multe decat tine. dupa ce trece de aprobare e vizibil pt toti

    00
  14. S-ar putea sa aiba un flag pe articole, ceva de genul „published” si motorul de cautare sa nu tina cont de el si sa indexeze tot. Cand dai click pe articol insa verifica daca este publicat si nu te lasa sa-l accesezi.

    00

Adaugă un comentariu

Câmpurile marcate cu * sunt obligatorii! Adresa de email nu va fi publicată.

1. Linkurile utile în context sunt binevenite.
2. Comentariile asumate fac bine la blăniță.
3. Șterg comentariile care îmi strică buna dispoziție.
4. Nu fiți proști, agramați sau agresivi la primele 50 comentarii aici.

Susținere

Susține acest blog cumpărând de la eMAG sau de la Finestore.