Pagine duplicate (su domini diversi) e filtri di google

[gik25]

Secondo me non è fisicamente possibile controllare se due pagine sono duplicate (intendo su domini diversi)...


Il N° di confronti è infatti pari a ((N*N)-N)/2 cioè a un numero molto simile al quadtato di N!

Anche applicando il confronto solo alle pagine con la massima probabilitò di essere simili (può darsi che google ci classifichi in sezioni semantiche in base alle pagine o in base al sito) il N° di confronti è comunque elevatissimo (imho un bot potrà separare tra qualche decina di sezioni senza commettere errori)


Anche volevdo confrontare solo una certa percentuale di siti per ogni categoria (magari quelli con le key principali più simili) credo che la cosa non sarebbe fattibile...

Le key principali infatti mi sembrano spesso abbastanza diverse anche tra siti molto simili...

Senza contare che questo sistema NON riduce il n° di accessi al DB....

Tuttavia non riesco a immaginare se la struttura dei DB (spesso a indice invertito) permetta confronti più rapidi...

Questa però è solo una mia teoria e mi chiedo se qualcuno abbia esperienze in proposito...

[weppos]

Originariamente inviato da gik25
Questa però è solo una mia teoria e mi chiedo se qualcuno abbia esperienze in proposito...

Possibile, impossibile, miracolo o meno al momento ho quasi sempre notato che domini doppi o multipli (intesi come mirror) con gli stessi contenuti sono mostrati una sola volta da google.

[PiccoloElfo]

se la tua formula è corretta ovviamente hai ragione, tuttavia bisogna vedere se esistono sistemi più semplici per effettuare tali controlli. Io non riesco a capacitarmi di una tale complessità. Voglio dire se (e sottolineo se) prendesse una pagina e la convertisse in semplice binario, quanto complesso può essere verificare se la serie di 1 e 0 coincidono o no?

[gik25]

Originariamente inviato da PiccoloElfo
se la tua formula è corretta ovviamente hai ragione, tuttavia bisogna vedere se esistono sistemi più semplici per effettuare tali controlli. Io non riesco a capacitarmi di una tale complessità. Voglio dire se (e sottolineo se) prendesse una pagina e la convertisse in semplice binario, quanto complesso può essere verificare se la serie di 1 e 0 coincidono o no?

Beh credo comunque tantissimo....

Es. 1000 pagine = 1 milione di confronti binari.

Un confronto richiede almeno un centinaio di operazioni (ma a essere proprio ottimisti) quindi ci vorrebbero già ore.

Se invece di mille pagine ne vuoi confrontare 10 volte tante la difficoltà aumenta di 100 volte!


L'unica quindi è limitare i confronti a settori strettissimi (10 pagine) ma come individui questi settori? In base alla posizione di una ricerca? Questa sarebbe l'unica possibilità... ma rallenterebbe moltissimo le ricerche... e l'efficacia? Due siti identici tenderebbero a stare vicini? Si forse se non ci fossero i link esterni...

Ma le mie sono tutte illazioni

[agoago]

Gik25 scusa ma cosa importa ad un motore di fare questa analisi in fase di ricerca (se ho ben capito che a questo frangente ti riferivi)? Un filtro e' dato da un blocco di pc o server che possono lavorare su questo aspetto anche per un mese di fila prima che sia messo online il nuovo db filtrato. Infatti, proprio per quanto dici, ci sarebbe gia' da stupirsi che ci riescano in questo lasso di tempo apparentemente enorme (per dei pc) solo per confrontare le pagine. Ma non si fermano a questo perche' non controllano solo se due pagine sono identiche o simili ma anche i pezzi di codice coincidenti con altre pagine. Verificano anche se 2 pagime apparentemente differenti tra loro (esempio una di 5k ed una di 40k) contengano 2 o 3 o 10 righe identiche (non ho idea del parametro) e comuni tra le 2 pagine. Infatti fino ad un po' di tempo fa molti spammer facevano le doorway ragionando cosi':
Voglio creare il body per 8 pagine. Prendo un blocco contente 2 pezzi di codici, esempio: code1 code2 (magari il code2 e' formato da 4 righe, chesso' una tabella). Poi un secondo blocco per esempio code3 e code4 poi un terzo blocco code5 e code6. Faccio girare il tutto ed ottengo 8 pagine formate dal seguente codice:

135
136
145
146
235
236
245
246

queste pagine gia' venivano mal considerate in quanto tutte avevano almeno i 2 terzi del codice uguale ad altre 3 pagine ma almeno erano tutte differenti. Capitava pero' che si dovesse fare altre 8 pagine ed allora per comodita' si prendeva il blocco 3 e per esempio lo si sostituiva la primo, ottenendo:

531
532
541
542
631
632
641
642

vero che anche queste erano sempre simili alle precedenti ma non si pensava fossero considerate identiche. Adesso non ci scommetterei un cent che la 135 non sia valutata identica alla 531. Pertanto anche con il migliore algoritmo di sort credo sia gia' durissima analizzare il db in un mese, immaginati in tempo reale. Penso anch'io che limitino le comparazioni ma forse non accorpando gruppi di dati da confrontare ma piuttosto escludendoli. Visto che illazzi tu allora illazzo anch'io, tanto siamo qui per ragionarci mica per azzeccarci e sparo che forse potebbero escludere dal confronto pagine con estensioni diverse (che mi frega di comparare un .txt con un .pdf?) o pagine con alto punteggio (una pagina a pr 7 sara' dura che sia una pagina di spam e pertanto non la confronto con altre pagine da pr7 in su) o una pagina di 3k (di codice) sara' dura che non sia uguale ad altre 1000 pagine di qualsiasi altra dimensione pertanto non la confronto (e' per questo che chi spamma di professione tende ad usare pagine piccine piccine come codice, poi magari ci mette 20k di key dentro) e via dicendo. Certo che questa cosa ci fa capire ancora una volta come per realizzare un motore serio ci vogliano veramente 2 palle cosi' (e se mi si permette la battuta ce ne vogliono altrettante per fregarlo).

[Merisi]

Abbozzo un'idea per l'identificazione di due pagine identiche:

per ogni pagina abbiamo:
.numero di caratteri: 4350
.numero di parole: 355
.numero di link :18
.peso in kb: 18
.caratteri del titolo:20
.ecc. ecc.
(non credo sia difficile trovare una ventina di voci)

Quindi lo scopo sarebbe di ottenere un numero unico per ogni pagina, potremmo per esempio unire i valori:
4350.355.18.20.ecc.ecc.
oppure
43503551820ecc.ecc.
alla fine avremmo un database con 2 colonne: l'url di ogni pagina e il numero quasi unico attribuito ad ogni pagina, ordinando il database per il numero identificativo saltano fuori le pagine con lo stesso numero e quindi le pagine uguali.
Nel caso il numero identificativo non sia affidabile all 100% seguirà il controllo completo, ma solo delle pagine con il numero identificativo uguale.

Il sistema potrebbe essere valido per trovare pagine identiche, e quindi eludibile togliendo o aggiungendo una parola, credo comunque che potrebbe essere l'idea base per arrivare ad una soluzione piuttosto semplice.

[ak76]

io sono google ...
spulcio miosito.it ...
poi spulcio tuosito.it perchè è linkato da miosito.it ...
guarda che strano ... dominio diverso ma "stesso server" ... controllo un po' di testi di uno e dell'altro e mi accorgo che uno dei 2 è un mirror ...
lascio indicizzato solo il + vecchio dei 2

quindi secondo me il primo controllo che fa google è sui siti lionkato tra loro o che si trovano sullo stesso server ...

[gik25]

Originariamente inviato da ak76
io sono google ...
spulcio miosito.it ...
poi spulcio tuosito.it perchè è linkato da miosito.it ...
guarda che strano ... dominio diverso ma "stesso server" ... controllo un po' di testi di uno e dell'altro e mi accorgo che uno dei 2 è un mirror ...
lascio indicizzato solo il + vecchio dei 2

quindi secondo me il primo controllo che fa google è sui siti lionkato tra loro o che si trovano sullo stesso server ...

Giusto!

Però se ho due hoster diversi...

[PiccoloElfo]

Originariamente inviato da gik25
Giusto!

Però se ho due hoster diversi...

e se invece sono addirittura nel medesimo sito? Mi spiego... oltre alla versione "classic" da tempo sto lavorando alla versione per palmari di sito, quindi con pagine più leggere ed una risoluzione inferiore rispetto alle normali pagine. Ovviamente il tutto è possibile attingendo (per i testi) ai medesimi database, quindi di fatto le pagine sono identiche per l'80%. Allo stato attuale sono "tradotte" nella versione pocket 19 sezioni su 38, quindi diverse centinaia di pagine. Come valuta questo mr. G? Poichè ho notato casi in cui compaiono entrambe e casi in cui la versione pocket è prima rispetto alla versione classic.