mboost-dp1
mod_rewrite i .htaccess
Først min .htaccess-fil:
Hvis man kigger på nedenstående link så ses det at Google har indekseret det samme indhold på en masse forskellige URL's:
http://www.google.dk/search?q=allintitle:danske+sp...
Den originale:
http://www.jacobworsoe.dk/danske-split-test-cases-...
Kan også findes via denne:
http://www.jacobworsoe.dk/spor-soegemaskinernes-ro...
Hvilket skyldes den måde min .htacess er lavet på. Kan den laves så man kun kan finde den på den originale URL, men den anden enten giver en 404 eller kan 301-redirectes til den originale?
Problematikken er forresten beskrevet her: http://www.thomas-rosenstand.dk/duplicate-content
RewriteRule ([0-9]+)/$ post.php?id=$1
Hvis man kigger på nedenstående link så ses det at Google har indekseret det samme indhold på en masse forskellige URL's:
http://www.google.dk/search?q=allintitle:danske+sp...
Den originale:
http://www.jacobworsoe.dk/danske-split-test-cases-...
Kan også findes via denne:
http://www.jacobworsoe.dk/spor-soegemaskinernes-ro...
Hvilket skyldes den måde min .htacess er lavet på. Kan den laves så man kun kan finde den på den originale URL, men den anden enten giver en 404 eller kan 301-redirectes til den originale?
Problematikken er forresten beskrevet her: http://www.thomas-rosenstand.dk/duplicate-content
Det skyldes den måde det er lavet på.
Den kigger efter tallet lige før den sidste / så uanset hvad der står inden, så vil den altså kunne finde noget, hvis der bare står et tal lige før sidste /.
Det skal den bare ikke kunne.
F.eks. skal http://www.domain.dk/-19/-19/-20/-19/-20/ give en fejl 404, mens http://www.domain.dk/-20/ skal virke.
Så jeg ved ikke om man kan tælle de slashes og give en 404 hvis url'en indeholder mere end 4 slashes?
Den kigger efter tallet lige før den sidste / så uanset hvad der står inden, så vil den altså kunne finde noget, hvis der bare står et tal lige før sidste /.
Det skal den bare ikke kunne.
F.eks. skal http://www.domain.dk/-19/-19/-20/-19/-20/ give en fejl 404, mens http://www.domain.dk/-20/ skal virke.
Så jeg ved ikke om man kan tælle de slashes og give en 404 hvis url'en indeholder mere end 4 slashes?
Jeg skal gerne sige at jeg har lavet det på den måde, simpelthen fordi jeg ikke ved bedre...
Men din idé er at lave en kolonne i min tabel som f.eks. hedder "danske-split-test-cases-17" som jeg så går ind og matcher, istedet for bare at matche id'et, altså "17"?
Men det undgår vel ikke at der kan stå en masse foran det i url'en som det er tilfældet nu?
Men din idé er at lave en kolonne i min tabel som f.eks. hedder "danske-split-test-cases-17" som jeg så går ind og matcher, istedet for bare at matche id'et, altså "17"?
Men det undgår vel ikke at der kan stå en masse foran det i url'en som det er tilfældet nu?
Jeps.Jace (6) skrev:Men din idé er at lave en kolonne i min tabel som f.eks. hedder "danske-split-test-cases-17" som jeg så går ind og matcher, istedet for bare at matche id'et, altså "17"?
Jo, fordi hvis id'et ikke findes, så sender du et 404 header.Jace (6) skrev:Men det undgår vel ikke at der kan stå en masse foran det i url'en som det er tilfældet nu?
I php kan det gøres med
<?php header("HTTP/1.0 404 Not Found"); ?>
#8
Konceptet er også navngivet som "slug" engang imellem.
En måde at lave et på er f.eks. sådan her
Og så evt. append -<postid>, samt have kolonnen i din database som unique, så du er sikker på det er et unique slug.
Konceptet er også navngivet som "slug" engang imellem.
En måde at lave et på er f.eks. sådan her
public static string GenerateSlug(string phrase)
{
string str = RemoveAccent(phrase).ToLower();
// invalid chars
str = Regex.Replace(str, @"[^a-z0-9\s-]", "");
// convert multiple spaces into one space
str = Regex.Replace(str, @"\s+", " ").Trim();
// cut and trim it
str = str.Substring(0, str.Length <= 45 ? str.Length : 45).Trim();
// hyphens
str = Regex.Replace(str, @"\s", "-");
return str;
}
Og så evt. append -<postid>, samt have kolonnen i din database som unique, så du er sikker på det er et unique slug.
Helt grundlæggende opstår fejlen fordi du ikke fortæller mod_rewrite hvor den skal starte og hvor den skal slutte med at finde din key.
Det er så også derfor du ser Googles crawler har indexeret praktisk talt samtlige kombinationer når man sætter dine links sammen - sådan arbejder den, og du "giver den lov"
Din rule kigger KUN på det allersidste der kommer FØR slash. Det der så kommer til sidst skal være ét til flere tal.
Når du nu er igang, og jeg kan næsten regne ud du gerne vil lave det newz har, i hvert fald på nyheder, hvor URLen er ID du mapper til din database. Jeg synes selv det er den fede, og rigtige, måde, det eneste det kræver er at dit script når du opretter en ny nyhed lige checker den valgte titel, der efterfølgende konverteres til URL ikke allerede er brugt.
På newz kan du se man har været nødsaget til at inkludere ID'et i forumdelen fordi man ikke kan være sikker på at vi, brugerne, altid laver unikke titler. ID'et ses til sidst i url i f.eks. denne tråd.
Mulig løsning:
^ = Fortæller at herfra skal mod_rewrite starte med at finde key(s)
$ = Indikere slut for identificering af keys
Ovenfor ville en gyldig URL (bogstaver fra a-z, tal fra 0-9 samt "-") derfor være:
Mens:
ikke ville pga. "slash" i key ikke er gyldigt.
Det er så også derfor du ser Googles crawler har indexeret praktisk talt samtlige kombinationer når man sætter dine links sammen - sådan arbejder den, og du "giver den lov"
Din rule kigger KUN på det allersidste der kommer FØR slash. Det der så kommer til sidst skal være ét til flere tal.
Når du nu er igang, og jeg kan næsten regne ud du gerne vil lave det newz har, i hvert fald på nyheder, hvor URLen er ID du mapper til din database. Jeg synes selv det er den fede, og rigtige, måde, det eneste det kræver er at dit script når du opretter en ny nyhed lige checker den valgte titel, der efterfølgende konverteres til URL ikke allerede er brugt.
På newz kan du se man har været nødsaget til at inkludere ID'et i forumdelen fordi man ikke kan være sikker på at vi, brugerne, altid laver unikke titler. ID'et ses til sidst i url i f.eks. denne tråd.
Mulig løsning:
RewriteEngine on
RewriteRule ^([a-z0-9-]+)/$ post.php?id=$1 [L]
ErrorDocument 404 /error404.php
^ = Fortæller at herfra skal mod_rewrite starte med at finde key(s)
$ = Indikere slut for identificering af keys
Ovenfor ville en gyldig URL (bogstaver fra a-z, tal fra 0-9 samt "-") derfor være:
http://www.jacobworsoe.dk/danske-split-test-cases-17/
Mens:
http://www.jacobworsoe.dk/noget/nogetandet/
ikke ville pga. "slash" i key ikke er gyldigt.
Ja,
Hverken
http://www.jacobworsoe.dk/kun-bogstaver-tal-123-samt-bindestreg-er-gyldige-efterfuldt-af-slash/
Hverken
http://www.jacobworsoe.dk/url-uden-slash
http://www.jacobworsoe.dk/url med mellemrum
http://www.jacobworsoe.dk/url-med/flere-slashes/[/code]
er gyldige, og fordi de ikke kan matche Rule, kastes din custom Fejl 404 på error404.php.
Fjernes sidste linie, ser brugeren browserens indbyggede Fejl 404 side.
Måske er den for stram nu, det kommer an på din struktur.
Frandsen: Jeg har fundet en artikel, som har en endnu mere elegant løsning med 301-redirect istedet for bare en 404. Den har jeg prøvet at implementere, og det virker rigtig godt:
http://blog.loevgaard.dk/undga-duplicate-content-p...
http://blog.loevgaard.dk/undga-duplicate-content-p...
Jeg kan ikke umiddelbart helt se hvor det elegante i den løsning ligger.
Hans argument med at "en ond konkurrent" jo kunne oprette falske links hvor artikel-navnet er ændret holder jo ikke en meter.
Hvad så hvis jeg i stedet ændre ID'en, så løser hans hjælpe-script jo intet?
Sådan vil det altid være når man opdeler key'en i brudstykker.
Det var jo også derfor jeg foreslog at hele key'en skal være ID. Den løsning kræver ingen hjælpe-scripts, og man skal da være mere end uopfindsom hvis man ikke kan komme på en unik titel hver gang?
Hans argument med at "en ond konkurrent" jo kunne oprette falske links hvor artikel-navnet er ændret holder jo ikke en meter.
Hvad så hvis jeg i stedet ændre ID'en, så løser hans hjælpe-script jo intet?
Sådan vil det altid være når man opdeler key'en i brudstykker.
Det var jo også derfor jeg foreslog at hele key'en skal være ID. Den løsning kræver ingen hjælpe-scripts, og man skal da være mere end uopfindsom hvis man ikke kan komme på en unik titel hver gang?
Sat på spidsen kan man sige hans "løsning" kun afhjælper et problem han selv har skabt.
Fordi
måske nok var tiltænkt
virker
også, fordi han kun kigger på sidste key, ID'en.
Så prøver han så at løse sit selvskabte duplicate content problem med et hjælpe-script.
Hvorfor ikke bare helt undgå flere muligheder, og lade hele URI'en være din ID?
Fordi
RewriteRule ^([a-zA-Z0-9\-]+)\-([0-9]+)/$
måske nok var tiltænkt
site.com/artikel-navn-144/
virker
site.com/noget-andet-144/
site.com/noget-helt-andet-144/
også, fordi han kun kigger på sidste key, ID'en.
Så prøver han så at løse sit selvskabte duplicate content problem med et hjælpe-script.
Hvorfor ikke bare helt undgå flere muligheder, og lade hele URI'en være din ID?
Hvis du tilføjer et R flag til din regel vil der redirectes:
RewriteRule ([0-9]+)/$ post.php?id=$1 [R]
Men det er muligvis ikke helt hvad du havde i tankerne.
Muligvis ønsker du noget i retning af:
RewriteRule ../([^/]+)/$ /$1/ [R]
RewriteRule ([0-9]+)/$ post.php?id=$1
Du er nødt til at holde øje med at reglerne ikke resulter i cykliske redirects. For at undersøge den slags er det bedre at bruge et kommandolinieværktøj som f.eks. wget i stedet for en browser, som kun viser hver enkelt URL en brøkdel af et sekund.
RewriteRule ([0-9]+)/$ post.php?id=$1 [R]
Men det er muligvis ikke helt hvad du havde i tankerne.
Muligvis ønsker du noget i retning af:
RewriteRule ../([^/]+)/$ /$1/ [R]
RewriteRule ([0-9]+)/$ post.php?id=$1
Du er nødt til at holde øje med at reglerne ikke resulter i cykliske redirects. For at undersøge den slags er det bedre at bruge et kommandolinieværktøj som f.eks. wget i stedet for en browser, som kun viser hver enkelt URL en brøkdel af et sekund.
Frandsen: Jeg kan godt se din pointe, men lige præcis i mit tilfælde, så virker løsningen jo perfekt. Da mit duplicate content problem lige præcis passer med det problem han har "konstrueret".
Og uden at brække key'en op har man jo ikke mulighed for at redirecte til den rigtige, men kun give en 404 hvis key'en ikke matcher noget i databasen.
Når Google har registreret min ændring og fjernet alle de forkerte url's fra deres indeks vil jeg dog ændre min struktur til en løsning med en samlet key.
Og uden at brække key'en op har man jo ikke mulighed for at redirecte til den rigtige, men kun give en 404 hvis key'en ikke matcher noget i databasen.
Når Google har registreret min ændring og fjernet alle de forkerte url's fra deres indeks vil jeg dog ændre min struktur til en løsning med en samlet key.
kasperd: Selve redirected bliver lavet i php filen, da jeg først checker om URL'en er rigtig og kun redirecter hvis den er forkert i forhold til det ID der er sendt med i URL'en.
Jeg har tjekket mit redirect med denne service:
http://www.seoconsultants.com/tools/headers
Det virker perfekt hvis man f.eks. smider denne ind:
Jeg har prøvet med curl som er indbygget på min Mac, men den skriver ikke noget hvis man giver den det ovenstående link. Så jeg må prøve at få smidt wget på maskinen istedet :)
Jeg har tjekket mit redirect med denne service:
http://www.seoconsultants.com/tools/headers
Det virker perfekt hvis man f.eks. smider denne ind:
http://www.jacobworsoe.dk/spor-soegemaskinernes-robotter-i-google-analytics-16/danske-split-test-cases-17/
Jeg har prøvet med curl som er indbygget på min Mac, men den skriver ikke noget hvis man giver den det ovenstående link. Så jeg må prøve at få smidt wget på maskinen istedet :)
Gå til top
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Programmering
Gå til bund