Er zijn nog een aantal zaken die vanuit het standpunt van zoekmachine-optimalisatie ten strengste te vermijden zijn. We zullen hier deze zaken overlopen. Een aantal andere dingen die moeten vermeden worden, worden beschouwd als spam en zullen daar behandeld worden.
Flash is evil
Macromedia Flash is zeer populair onder grafisch designers. Met Flash kan je dan ook dingen doen die anders onmogelijk waren. Vanuit zoekmachine-optimalisatie-standpunt echter is Flash een door in het oog. Er zijn nog een aantal andere zaken die door tegenstanders van Flash worden opgenoemnd, maar die zijn hier niet ter zake.
Eerst en vooral is het zo dat de teksten die in Flash applicaties verwerkt zitten niet door de zoekmachines gelezen kunnen worden. Er kunnen dus ook geen credits worden opgebouwd voor de keywords die hier terug te vinden zijn.
Wanneer de hele site in Flash is opgebouwd geeft dit natuurlijk serieuse problemen, want hoe moet je dan verwachten dat je site nog te vinden is in de zoekmachineS?
Verder moet Flash meestal eerst een tijdje laden omdat het nogal groot is. In ieder geval veel groter dan de normale tekst en beelden die op een website terug te vinden zijn. Dit is ook nadelig voor de zoekresultaten. Hoe langer het duurt om de site te laden, hoe minder vaak spiders de site gaan crawlen om te zien of er nieuwe dingen op staan en hoe kleiner de kans dat alle pagina's geindexeerd worden.
Gebruik Flash dus best alleen waarvoor het best dienst: het opvrolijken van het geheel of het illustreren van bepaalde zaken die anders onmogelijk te illustreren zijn. Zo houdt je de tekst leesbaar voor de zoekmachines en heb je nuttige content die wordt geindexeerd. Verder hou je de Flash applicaties best klein, zodat het niet te lang duurt vooraleer de site geladen is. Zo bevorder je het crawlen en indexeren van de site.
Hoewel de zoekmachines bekijken hoe ze ook Flash animaties kunnen indexeren, is het gebruik van Flash zeker af te raden vanuit zoekmachine optimalisatie standpunt.
Java
Een zelfde redenering gaat op voor Java Applets. Vaak worden Java Applets gebruikt om de site op te vrolijken. Java laadt gewoonlijk nog trager dan Flash en vaak zijn er problemen met het laden van de class bestanden om wille van incompatibele virtuele machines. Java applets zijn uitermate geschikt voor serieuse applicaties, maar niet voor zoekmachine optimalisatie. Dezelfde twee redenen als hierboven gelden hier ook: kan niet geindexeerd worden en laadt traag.
Frames
Ook de veelgebruikte techniek met frames moet vermeden worden als je de site wil optimaliseren voor zoekmachine optimalisatie. Er zijn een groot aantal nadelen verbonden met frames (ivm toegankelijkheid, opslaan in favoriete, etc.), waaronder dus ook een zoekmachine-optimalisatie probleem.
Het probleem is dat niet alle zoekmachines frames-pagina's kunnen indexeren, en alle zoekmachines hebben er problemen mee. Het is dan ook niet duidelijk hoe de verschillende pagina's moeten geindexeerd worden. Vaak krijg je dan een pagina in de SERP's die eigenlijk ergens in een frame had moeten terechtkomen. Gebruikers die dan op de site terecht komen zien enkel die pagina en vragen zich af waar bijvoorbeeld het menu staat. Dat kunnen ze enkel bereiken door handmatig in de adresbalk naar het hoofddomein te gaan (er zal iets staan van www.mijnpagina.be/subcategorie/producti.html).
Stel nu dat de zoekmachine dit wou voorkomen door alleen het hoofd-domein te indexeren (www.mijnpagina.be). Dan zou de persoon die op de link in de SERP's klikt doorverwezen worden naar de homepagine, en dus niet op de juiste pagina terecht komen. Een beetje hetzelfde probleem als bij het proberen toevoegen van een subpagina aan de favorieten.
En toch worden frames nog bijzonder veel gebruikt. Heel veel pagina's zondigen dus nog en zijn heel slecht vindbaar in de zoekmachines.
En er is nog een zaak ivm frames waar veel sites op zondigen. Veel van die websites worden ontwikkeld dmv een ontwikkeltool (vaak bvb Frontpage). En er worden voor de verschillende subpagina's dan geen beduidende namen gekozen. Vaak kom je zo tot pagina's met titels als "nieuwe pagina 3" en dergelijke. Het hoeft geen betoog dat dergelijke pagina's niet scoren in de SERP's.
zaterdag, december 10, 2005
dinsdag, december 06, 2005
Zoekmachine vriendelijke redirect
De zoekmachine vriendelijke Redirect
Een van de best bekende zoekmachine optimalisatie technieken is het gebruiken van zoekmachine vriendelijke redirects. Het is alom bekend dat zoekmachines problemen hebben met een 302 redirect in de header. Vooral Google en 302 redirects zijn geen al te beste vrienden, hoewel Google een aantal aanpassingen in het algoritme heeft gedaan zodat ook 302 redirects nu worden opgenomen in de index. Het probleem is eigenlijk een logisch gevolg van de semantiek van de redirects. Een 301 redirect is een Permanente redirect en een 302 redirect is een temporele redict. Dat staat zelfs mee in de return van de redirect: "301 Permanently Moved". Toch komt de 302 redirect soms nog voor bij mensen die een permanente redirect willen doorvoeren. Ook andere zoekmachine onvriendelijke redirects komen voor. Een van de meest voorkomende is de meta-refresh redirect. In tegenstelling tot een verkeerd soort redirect (zoals bij 301/302) is dit een verkeerde techniek. Ook de url-forwarding die sommige domeinnaam hosting bedrijven aanbieden is onveilig.
Het probleem met 302 redirect zit hem in het feit dat de nieuwe pagina wordt bekeken als inhoud van de eerste pagina. De oude pagina wordt meestal ook niet uit de index gehaald. Zoekmachines interpreteren de 302 redirect elks op een andere manier en er duiken zo problemen op ivm hijacks en duplicate content filters. Dit valt echter buiten het bestek van deze tekst.
De HTTP-redirect
Een eerste manier is de meta-refresh redirect. Dit is een zeer veel voorkomende vorm van redirect en het is dus belangrijk dat je ervoor op je hoede bent. Deze redirect geef je mee in een meta tag in de header van het html document. Het ziet er allemaal zo uit:
<META HTTP-EQUIV=Refresh CONTENT="0; URL=http://www.nieuwdomain.com">
Je kan dus een aantal seconden meegeven (hier 0) gedurende dewelke de pagina moet weergegeven worden vooraleer de nieuwe pagina wordt geladen. Dit soort redirect wordt vaak gebruikt bij het wijzigen van domein of pagina met de vermelding "Onze website is verhuist naar www.nieuwesite.be, u wordt automatisch doorverwezen. Indien de nieuwe pagina niet automatisch wordt weergegeven, klik dan hier". De meeste zoekmachines indexeren deze pagina gewoon met de tekst "onze website is ..". Een aantal zoekmachines (de belangrijkste) is intelligent genoeg om de redirect te herkennen. Zij zien dan hoe lang de time-out is. Indien de time-out zeer kort is en korter dan de gemiddelde tijd om een pagina te laden, wordt de nieuwe pagina bekeken. Indien de tijd te lang is wordt de pagina zelf gewoon geindexeerd.
Maar indien de tijd zeer kort is zou de redirect aanzien worden als een 302 redirect, en niet als een 301 redirect. En een 302 redirect is nu eenmaal niet zoekmachine vriendelijk. Dus proberen we dit soort redirect beter te vermijden.
Yahoo heeft bekendgemaakt hoe het dit soort redirect behandeld. Een meta refresh van 0 seconden wordt aanzien als een 301 redirect. Vanaf meer dan 1 seconde wordt de redirect aanzien als een 302 redirect. Msn zegt dat ze een meta-refresh redirect zien als een 302 redirect en Ask Jeeves ziet een meta-refresh van 0 seconden aan als een 302 redirect, maar wacht tot er meer duidelijkheid is over de redirect vooraleer de index te updaten.
Elke zoekmachine heeft dus een andere manier om de redirectie te interpreteren en het is vanuit zoekmachine-optimalisatie standpunt dus beter om deze redirect te vermijden. Als je hem toch nodig hebt omdat de andere methodes bijvoorbeeld niet binnen de mogelijkheden liggen, gebruik je best een redirect van 0 seconden. Die wordt dan in de meeste gevallen geïnterpreteerd als een 302 redirect, behalve bij Yahoo.
De Script-redirect
Een andere manier om te redirecten van de client-side is door middel van een client script zoals JavaScript. Zoekmachines zullen een dergelijke JavaScript redirect niet herkennen en dus ook niet volgen. Sommige mensen zagen zo de kans van hun leven om de zoekmachines te misleiden. Ze maakten een pagina vol keywords en lieten een JavaScript de pagina doorverwijzen naar de echte pagina. De zoekmachines zien alleen de originele pagina en ranken die dus hoog in de SERPS. Vorig jaar echter werd het algoritme Google slim genoeg om dergelijke redirects te herkennen en werden er een hele hoop pagina's uit de lijsten gebanned of omlaag gehaald.
Het komt er dus op neer dat de redirect niet herkend wordt door de zoekmachines en dat het gebruik ervan ertoe kan leiden dat de site gebanned wordt. Het is dus absoluut belangrijk deze methode te vermijden! Om volledig te zijn neem ik hier toch 2 voorbeeld code snippets op waarmee dergelijke redirect mogelijk is:
JavaScript Redirect - Niet gebruiken!
<script type="text/javascript">
<!--
window.location = "http://www.nieuwesite.be/"
//-->
</script>
<body onLoad="setTimeout(location.href='http://www.nieuwesite.be', '0')" >
De 301 redirect
Het is dus belangrijk te kiezen voor een goede redirect, dwz de 301 redirect. Omdat hij zo belangrijk is geef ik hier alle manieren om hem te bewerkstelligen in client-side script en programmeertalen. Daarna geef ik de mogelijkheden om het in de apache server in te stellen in de .htaccess en een alternatieve mogelijkheid met de CNAME.
PHP 301 Redirect voorbeeld
header("HTTP/1.1 301 Moved Permanently");
header("Location: http://www.nieuwdomein.be/nieuwedir/nieuwe-pagina.htm");
exit();
ASP 301 Redirect voorbeeld (VBScript)
<%@ Language=VBScript %>
<%
Response.Status="301 Moved Permanently"
Response.AddHeader "Location", "http://www.nieuwdomein.be/nieuwedir/nieuwe-pagina.asp"
response.end
%>
ASP 301 Redirect voorbeeld (JScripit)
<%@ Language=VBScript %>
<%
Response.Status="301 Moved Permanently"
Response.AddHeader "Location", "http://www.nieuwdomein.be/nieuwedir/nieuwe-pagina.asp"
response.end
%>
ASP .NET 301 Redirect voorbeeld (c#)
<script runat="server">
private void Page_Load(object sender, System.EventArgs e) {
Response.Status = "301 Moved Permanently";
Response.AddHeader("Location","http://www.newdomein.be/");
}
</script>
Cold Fusion 301 Redirect voorbeeld (CFM)
<.cfheader statuscode="301" statustext="Moved permanently">
<.cfheader name="Location" value="http://www.nieuwdomein.be/">
JSP / Java Servlets / Java 301 Redirect voorbeeld (Java)
<%
repsonse.setStatus(301);
response.setHeader( "Location", "http://www.nieuwdomein.be/" );
response.setHeader( "Connection", "close" );
%>
CGI / Perl 301 Redirect voorbeeld
#! /usr/bin/perl
use cgi;
my $q = cgi->new();
print $q->redirect(
-location => 'http://www.newsite.com/nieuwe-pagina.cgi',
-status => 301,
);
Als je te maken hebt met html-pagina's bestaat er toch de mogelijkheid om de soort redirects te implementeren. Je kan immers in de .htacces de html pagina's ook laten interpreteren als scripting pagina's zodat ze geparsed worden. Hiervoor gebruik je dan volgende regels in de .htaccess:
AddType application/x-httpd-php .html
AddType application/x-httpd-php .htm
301 Redirect in de htaccess
Een mooie en krachtige manier om een redirect te doen is in de .htaccess. We hebben de .htaccess reeds eerder gezien in het stuk over domeinnamen en subomeinen en het herschrijven van url's met mod rewrite.
Als je beschikt over Apache en mod_rewrite is geinstalleerd, dan kan je de redirect inderdaad mooi daar zetten ipv in de broncode van de pagina's. De syntax van de redirect in de htaccess (heb je geen mod rewrite voor nodig) is als volgt:
Redirect /uwdirectory http://www.nieuwdomein.told/nieuwedirectory
Maar de default waarde geeft een 302, en zoals we reeds eerder gezien hebben willen we zeker geen 302 redirect. Je kiest dus best een van de volgende varianten:
Redirect permanent /one http://www.nieuwdomein.be/two
Redirect 301 /two http://www.nieuwdomein.be/other
Zo ben je er zeker van dat Apache een 301 zoekmachine vriendelijke redirect teruggeeft. Je kan zoals we gezien hebben met die mod rewrite ook de url's herschrijven en bijvoorbeeld .php bestanden hernoemen naar .html bestanden. Je kan met mod rewrite nog veel meer dan met de gewone redirect in de htaccess. Maar als je geen bevoegdheden hebt om de mod rewrite te installeren kan je zo al verder. Wanneer je een domein wilt forwarden naar een nieuw domein kan je deze code gebruiken met mod rewrite:
Options +FollowSymLinks
RewriteEngine on
RewriteCond %{HTTP_HOST} ^newdomain\.com
RewriteRule ^(.*)$ http://www.nieuwdomein.be/$1 [R=permanent,L]
301 Redirect mbv de CNAME
Een laatste manier om een redirect te bewerkstelligen is dmv het CNAME veld op de server. Deze CNAME wordt meestal gebruikt als alias voor een subdomein dat ergens anders gehost is. Een voorbeeld is wanneer www.domeinnaam.be wordt doorverwezen naar domeinnaam.be. In Apache is de server respons voor een dergelijke redirect 301, dus kan je de CNAME in principe gebruiken als zoekmachine-vriendelijke redirect. Mijn ervaring is dat dit inderdaad goed werkt.
Je kan natuurlijk alleen subdomeinen doorverwijzen met de CNAME. Verder is dit geen echte methode voor beginnende webontwikkelaars. Bij een slechte configuratie van de CNAME kan je zelfs in een oneindige lus raken of kan er voor zorgen dat je mails niet meer aankomen. Daarom is het gebruik van een CNAME eigenlijk niet zo aangewezen. Het wordt dan ook meestal enkel gebruikt wanneer een subdomein verwijst naar een nieuw domein.
Wat kan en niet kan
Tot zover hebben we enkel zaken besproken die belangrijk zijn bij de zoekmachine optimalisatie om te implementeren.
Natuurlijk zijn er ook zaken die je absoluut moet vermijden. Er bestaan technieken en werkwijzen die soms heel handig zijn of mooie resultaten opleveren, maar die absoluut te vermijden zijn bij het ontwerpen of ontwikkelen van een website.
Sommige van deze technieken worden ook aanzien als spam en zullen in die sectie nog terugkomen.
In eerste instantie zullen we de redirect in al zijn vormen bekijken. Het gebruik van een verkeerde redirect is een van de meest voorkomende fouten die beginnende webmasters maken.
Natuurlijk zijn er ook zaken die je absoluut moet vermijden. Er bestaan technieken en werkwijzen die soms heel handig zijn of mooie resultaten opleveren, maar die absoluut te vermijden zijn bij het ontwerpen of ontwikkelen van een website.
Sommige van deze technieken worden ook aanzien als spam en zullen in die sectie nog terugkomen.
In eerste instantie zullen we de redirect in al zijn vormen bekijken. Het gebruik van een verkeerde redirect is een van de meest voorkomende fouten die beginnende webmasters maken.
vrijdag, december 02, 2005
domeinnaam en url (rewrite)
de domeinnaam
Een ander belangrijke eigenschap van de website ivm zoekmachine optimalisatie of pagina is de domeinnaam waaronder ze te vinden is. Het belangrijkste keyword komt best in de domeinnaam voor. Vaak is dit bijvoorbeeld een bedrijfsnaam. Als je bijvoorbeeld hoog wilt scoren voor Quick, dan kies je best voor Quik.tld.
Wat als je bedrijfsnaam nu uit meerdere woorden bestaat? Je schoonheidssalon heet bijvoorbeeld Perfect Body. Dan kan je best kiezen voor het streepje tussen de twee delen. perfect-body.be is dus beter dan perfectbody.be. Dat komt omdat de zoekmachines woorden die verboden zijn met een streepje lezen als een samenhangende woordgroep. Ze zien perfect-body dus als "perfect body" en perfectbody als ... perfectbody.
de subdomeinen
Subdomeinen worden door de zoekmachines aanzien als aparte domeinen. Wanneer je dus met verschillende subdomeinen zit, worden die aanzien als aparte websites. Je kan die sites dan interlinken, zodat ze elkaar voeden met links. Uiteraard moet je ook opletten dat je geen dubbele informatie beschikbaar stelt. Dan treedt de dupblicate content filter in werking en zal slechts een van de sites krediet krijgen voor de content. De kans is er dan dat de andere site een beetje naar achteren geschoven wordt.
oppassen met de www!
Er is heel weinig dat andere mensen kunnen doen om jouw site naar beneden te halen in de zoekmachine resultaten. Maar er is een ding dat werkt en waar je jezelf voor moet behoeden. De situatie komt voor wanneer www.website.com dezelfde resultaten geven als website.com, zonder dat er wordt doorverwezen, of toch zeker zonder dat er wordt doorverwezen met een zoekmachine-vriendelijke 301 Redirect.
Naar deze situatie wordt verwezen als "Search Engine Sabbotage". Een volledige uitleg vind je op http://www.threadwatch.org/node/2817 . Het komt er op neer dat wanneer zowel de www. als de versie zonder www. (bvb www.vanderhovenss.be en vanderhovenss.be) dezelfde pagina weergeven (door technische instellingen op de server), dit door Google als twee aparte domeinen en dus sites wordt behandeld. Google zal dan de duplicate content filter activeren en de sites zullen elks apart in de zoekresultaten terecht komen, elks met een lagere ranking dan wanneer slechts ��n van beiden in de resultaten terecht zou komen.
Om dit te vermijden moet je een van de twee versies (bvb. diegene zonder de www) laten doorverwijzen naar de andere versie (bvb die met de www). Dit moet natuurlijk op een zoekmachine vriendelijke manier, met een 301 Permanente redirect. Dit kan bijvoorbeeld met php code of in de htaccess.
Met php code kan een redirect er als volgt uitzien:
Voor de redirect in de htaccess stond er op SEOMoz een interessante link naar threadwatch.org (zie boven) waarin volgende code werd vermeld (wordt onder ander gebruikt op vanderhovenss.be :
#------------------------------------------
# First optional line, include only in case of errors:
RewriteEngine On
# Second optional line, include only in case of errors:
Options +FollowSymLinks
# Optional start tag, requires use of corresponding end tag as well
< IfModule mod_rewrite.c >
# ----------------- the real stuff starts here
# IF there's a host field at all, AND
RewriteCond %{HTTP_HOST} .
# IF domain does not start with www, AND
RewriteCond %{HTTP_HOST} !^www\.threadwatch
# IF subdomain is not another one of those you like
RewriteCond %{HTTP_HOST} !^sub1\.threadwatch [NC]
RewriteCond %{HTTP_HOST} !^sub2\.threadwatch [NC]
RewriteCond %{HTTP_HOST} !^sub3\.threadwatch [NC]
RewriteCond %{HTTP_HOST} !^sub4\.threadwatch [NC]
RewriteCond %{HTTP_HOST} !^sub5\.threadwatch [NC]
# THEN redirect everything to an appropriate location
RewriteRule (.*) http //www.threadwatch.org/$1 [R=301,L]
# ----------------- the real stuff ends here
# Optional end tag, only if you have used the optional start tag
< /IfModule >
#------------------------------------------
De andere pagina's met mod rewrite
Ook de andere pagina's kan je best niet zo laten indien ze dynamisch gegenereerd worden. Meestal zal je pagina's krijgen in de vorm:
index.php?page=hoofdpagina&sub=subpagina&id=23
Dit is niet aan te raden voor opname in de zoekmachines. Veel zoekmachines hebben het niet zo met dynamische url's en zullen de url's niet opnemen in hun index. Google formuleert het in zijn tips voor webmasters als volgt:
Vooral wanneer er een SESSIONID in de url wordt bijgehouden zullen de url's niet opgenomen worden. Er wordt ook gezegd dat url's met id= niet worden opgenomen, maar dat is verkeerde informatie. De nieuwsartikels op vanderhovenss.be worden voorlopig nog op deze oude manier benaderd. Een voorbeeld van een nieuwsbericht is dat van "Google straft msn.com?", met als url: http://www.vanderhovenss.be/index.php?page=nieuws&id=69. Dit artikel werd bijvoorbeeld opgenomen in de index van google. Net als alle andere nieuwsartikels.
Beter is het dus om met mod rewrite de verschillende url's te herschrijven naar beter leesbare url's. Dit is bijvoorbeeld toegepast bij De Hongerkiller. In plaats van iets als index.php?pagina=frietkraam is de url nu http://www.dehongerkiller.be/frietkraam. Omdat frietkraam nu mee in de url voorkomt krijgt deze url meer krediet voor het keyword frietkraam. Bovendien is de url zoekmachinevriendelijk en kan hij door alle zoekmachines zonder meer geindexeerd worden. Sommige seo-consultants kiezen ervoor om met mod rewrite de url te herschrijven naar www.domein.tld/pagina.htm . Ze gaan er van uit dat .htm bestanden beter geindexeerd worden omdat ze statisch zijn. Op fora wordt toch steeds tegengesproken dat dit waar zou zijn en ikzelf heb ook niet die indruk.
Een voorbeeld van zo'n rewrite (anders dan in het vorige voorbeeld) is bijvoorbeeld:
Je kan dan met /sitemap verwijzen naar de sitemap!
Herschrijven die url's dus!!
Een ander belangrijke eigenschap van de website ivm zoekmachine optimalisatie of pagina is de domeinnaam waaronder ze te vinden is. Het belangrijkste keyword komt best in de domeinnaam voor. Vaak is dit bijvoorbeeld een bedrijfsnaam. Als je bijvoorbeeld hoog wilt scoren voor Quick, dan kies je best voor Quik.tld.
Wat als je bedrijfsnaam nu uit meerdere woorden bestaat? Je schoonheidssalon heet bijvoorbeeld Perfect Body. Dan kan je best kiezen voor het streepje tussen de twee delen. perfect-body.be is dus beter dan perfectbody.be. Dat komt omdat de zoekmachines woorden die verboden zijn met een streepje lezen als een samenhangende woordgroep. Ze zien perfect-body dus als "perfect body" en perfectbody als ... perfectbody.
de subdomeinen
Subdomeinen worden door de zoekmachines aanzien als aparte domeinen. Wanneer je dus met verschillende subdomeinen zit, worden die aanzien als aparte websites. Je kan die sites dan interlinken, zodat ze elkaar voeden met links. Uiteraard moet je ook opletten dat je geen dubbele informatie beschikbaar stelt. Dan treedt de dupblicate content filter in werking en zal slechts een van de sites krediet krijgen voor de content. De kans is er dan dat de andere site een beetje naar achteren geschoven wordt.
oppassen met de www!
Er is heel weinig dat andere mensen kunnen doen om jouw site naar beneden te halen in de zoekmachine resultaten. Maar er is een ding dat werkt en waar je jezelf voor moet behoeden. De situatie komt voor wanneer www.website.com dezelfde resultaten geven als website.com, zonder dat er wordt doorverwezen, of toch zeker zonder dat er wordt doorverwezen met een zoekmachine-vriendelijke 301 Redirect.
Naar deze situatie wordt verwezen als "Search Engine Sabbotage". Een volledige uitleg vind je op http://www.threadwatch.org/node/2817 . Het komt er op neer dat wanneer zowel de www. als de versie zonder www. (bvb www.vanderhovenss.be en vanderhovenss.be) dezelfde pagina weergeven (door technische instellingen op de server), dit door Google als twee aparte domeinen en dus sites wordt behandeld. Google zal dan de duplicate content filter activeren en de sites zullen elks apart in de zoekresultaten terecht komen, elks met een lagere ranking dan wanneer slechts ��n van beiden in de resultaten terecht zou komen.
Om dit te vermijden moet je een van de twee versies (bvb. diegene zonder de www) laten doorverwijzen naar de andere versie (bvb die met de www). Dit moet natuurlijk op een zoekmachine vriendelijke manier, met een 301 Permanente redirect. Dit kan bijvoorbeeld met php code of in de htaccess.
Met php code kan een redirect er als volgt uitzien:
< ?php if ($_SERVER['HTTP_HOST'] != "www.example.com") {
header("HTTP/1.1 301 Moved Permanently");
header("Location: http://www.example.com".$_SERVER['REQUEST_URI']);
exit; }
else {
// your usual HTTP headers go here
};
? >Voor de redirect in de htaccess stond er op SEOMoz een interessante link naar threadwatch.org (zie boven) waarin volgende code werd vermeld (wordt onder ander gebruikt op vanderhovenss.be :
#------------------------------------------
# First optional line, include only in case of errors:
RewriteEngine On
# Second optional line, include only in case of errors:
Options +FollowSymLinks
# Optional start tag, requires use of corresponding end tag as well
< IfModule mod_rewrite.c >
# ----------------- the real stuff starts here
# IF there's a host field at all, AND
RewriteCond %{HTTP_HOST} .
# IF domain does not start with www, AND
RewriteCond %{HTTP_HOST} !^www\.threadwatch
# IF subdomain is not another one of those you like
RewriteCond %{HTTP_HOST} !^sub1\.threadwatch [NC]
RewriteCond %{HTTP_HOST} !^sub2\.threadwatch [NC]
RewriteCond %{HTTP_HOST} !^sub3\.threadwatch [NC]
RewriteCond %{HTTP_HOST} !^sub4\.threadwatch [NC]
RewriteCond %{HTTP_HOST} !^sub5\.threadwatch [NC]
# THEN redirect everything to an appropriate location
RewriteRule (.*) http //www.threadwatch.org/$1 [R=301,L]
# ----------------- the real stuff ends here
# Optional end tag, only if you have used the optional start tag
< /IfModule >
#------------------------------------------
De andere pagina's met mod rewrite
Ook de andere pagina's kan je best niet zo laten indien ze dynamisch gegenereerd worden. Meestal zal je pagina's krijgen in de vorm:
index.php?page=hoofdpagina&sub=subpagina&id=23
Dit is niet aan te raden voor opname in de zoekmachines. Veel zoekmachines hebben het niet zo met dynamische url's en zullen de url's niet opnemen in hun index. Google formuleert het in zijn tips voor webmasters als volgt:
If you decide to use dynamic pages (i.e., the URL contains a "?" character), be aware that not every search engine spider crawls dynamic pages as well as static pages. It helps to keep the parameters short and the number of them few.
Vooral wanneer er een SESSIONID in de url wordt bijgehouden zullen de url's niet opgenomen worden. Er wordt ook gezegd dat url's met id= niet worden opgenomen, maar dat is verkeerde informatie. De nieuwsartikels op vanderhovenss.be worden voorlopig nog op deze oude manier benaderd. Een voorbeeld van een nieuwsbericht is dat van "Google straft msn.com?", met als url: http://www.vanderhovenss.be/index.php?page=nieuws&id=69. Dit artikel werd bijvoorbeeld opgenomen in de index van google. Net als alle andere nieuwsartikels.
Beter is het dus om met mod rewrite de verschillende url's te herschrijven naar beter leesbare url's. Dit is bijvoorbeeld toegepast bij De Hongerkiller. In plaats van iets als index.php?pagina=frietkraam is de url nu http://www.dehongerkiller.be/frietkraam. Omdat frietkraam nu mee in de url voorkomt krijgt deze url meer krediet voor het keyword frietkraam. Bovendien is de url zoekmachinevriendelijk en kan hij door alle zoekmachines zonder meer geindexeerd worden. Sommige seo-consultants kiezen ervoor om met mod rewrite de url te herschrijven naar www.domein.tld/pagina.htm . Ze gaan er van uit dat .htm bestanden beter geindexeerd worden omdat ze statisch zijn. Op fora wordt toch steeds tegengesproken dat dit waar zou zijn en ikzelf heb ook niet die indruk.
Een voorbeeld van zo'n rewrite (anders dan in het vorige voorbeeld) is bijvoorbeeld:
RewriteRule ^sitemap* index.php?page=sitemapJe kan dan met /sitemap verwijzen naar de sitemap!
Herschrijven die url's dus!!
Abonneren op:
Posts (Atom)