De PHPhulp kroeg
URL rewrite en htaccess
Ik ben voor een site bezig met het verbeteren van de SEO. Nou wil ik graag de URL verbeteren door middel van tekst in plaats van id's in de URL.
Voorbeeld: www.domein.nl/pagina/?id=1&pagina=functie&jaar=2019
ID 1 is bijvoorbeeld jan-peter-balkenende. En ik zou dan de URL willen wijzigen in: www.domein.nl/pagina/jan-peter-balkenende/functie/2019. Ik had alleen een paar vragen die bij me op komen.
- Moet ik dan in de database voor elke persoon een unieke URL-naam opslaan zoals ID 1 = jan-peter-balkenende? Of wat is hierbij gebruikelijk? En dan in plaats van zoeken op ID 1 zoeken op jan-peter-balkenende?
- Is er een mogelijkheid waarbij de oude URL blijft werken? Die staan nu namelijk op Google. Blijven die zo bruikbaar, of kan ik die dan op één of andere manier verwijzen?
Dan krijg je dus een URL zoals: www.website.nl/nieuws/5/nieuwe-website-geintroduceerd.html
Hierbij kijk verplicht ik de slug overigens niet, en is deze ook niet de sleutel in de URL. Als iemand de slug in de URL aanpast, dan laat ik een redirect uitvoeren naar de juiste slug:
www.website.nl/nieuws/5/nieuwe-website-geintroduceerd-bla-die-bla.html
komt weer uit op:
www.website.nl/nieuws/5/nieuwe-website-geintroduceerd.html
Omdat de slug niet de sleutelrol speelt, kan deze ook uit de URL gelaten worden, en in dat geval redirect ik automatisch naar dezelfde site, maar dan mét de slug.
Ik moet het htaccess nog een beetje onder de knie krijgen, dus probeer het eerst even helder te krijgen hoe en wat.
Als je geen ID's in de URL wilt tonen, en dus unieke titels hebt, dan moet je wel de slug opslaan.
Ik had wat rondgezocht omdat mijn interesse was gewekt hoe anderen het doen, maar zie dat NOS de id en titel samenvoegt (en daarna split ofzo?) en dat NU.nl zowel een ID als slug gebruikt. Maar bij VI.nl zie ik geen ID's in de URL, die zoeken dus ook op de slug neem ik aan?
Het idee hierbij is (waarschijnlijk) wel altijd de aanwezigheid van één voordeur (single point of entry) in je applicatie. Dit is meestal gewoon index.php. Toegepast op de vorige strategieën vraag je in het eerste geval in index.php de informatie (bijna) rechtstreeks op, en in het tweede geval delegeer je code vanuit index.php verder naar een andere lap code die het request (de pagina aanroep) verder afhandelt.
.htaccess
Code (php)
1
2
3
2
3
# Rewrite for kalender
RewriteEngine On
RewriteRule ^/?([^/]*)?/?([^/]*)?/ index.php?jaar=$1&cat=$2 [NC,QSA,L]
RewriteEngine On
RewriteRule ^/?([^/]*)?/?([^/]*)?/ index.php?jaar=$1&cat=$2 [NC,QSA,L]
index.php
Code (php)
Op het moment dat ik 'jaar' leeglaat, dus /jaar/categorie/ doe als //xxxx/ dan verspringt xxxx alsware van categorie naar jaar. Niet dat het heel belangrijk is, maar hoort dat zo? Nu kan ik bijvoorbeeld een handeling uitvoeren als jaar niet voorkomt in de array of empty is. Ik heb ze voorlopig namelijk op optioneel gezet als het goed is, al weet ik niet of ik dat zo laat.
Bij pagination en zoekresultaten kan ik het beste gewoon ?a=1&b=2&filter=3&q=blabla laten achter de rewrite? En voor pagina's die bij Google in de zoekresultaten moeten komen de URL rewriten (de canonical)?
Waar ik alleen niet uitkom is hoe ik dit moet toepassen op mijn website. Ik gebruik gedeeltelijk namelijk Wordpress - vanwege het usersysteem - maar voor het aanroepen van de database gegevens etc staat het eigenlijk los van Wordpress. Dit staat nu bij de .htaccess (heb ik niks aan veranderd):
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
# BEGIN LSCACHE
# END LSCACHE
# BEGIN NON_LSCACHE
# END NON_LSCACHE
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress
# Block WordPress xmlrpc.php requests
<Files xmlrpc.php>
order deny,allow
deny from all
allow from 123.123.123.123
</Files>
# END LSCACHE
# BEGIN NON_LSCACHE
# END NON_LSCACHE
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress
# Block WordPress xmlrpc.php requests
<Files xmlrpc.php>
order deny,allow
deny from all
allow from 123.123.123.123
</Files>
Ik heb bijvoorbeeld de pagina kalender/index.php?jaar=2019&cat=xxxx die door Wordpress/htaccess wordt herschreven naar kalender/?jaar=2019&cat=xxxx. Maar kan ik die dan weer herschrijven naar kalender/2019/xxxx? Dat krijg ik nog niet voor elkaar hoe dat zou moeten.
Als je een applicatie X hebt die volgens dit principe werkt kun je gewoon het beste alle verzoeken in eerste instantie naar de voordeur van applicatie X sturen. Vervolgens kun je in de applicatie zelf de URL verder ontleden.
Concreet zou ik dus alles van de vorm /kalender/* doorsturen naar /kalender/index.php. Dit is de enige RewriteRule die je nodig hebt. In /kalender/index.php kun je verder precies programmeren wat er dient te gebeuren. Dit beslis je op grond van de inhoud van de oorspronkelijk aangeroepen URL, die te vinden is onder $_SERVER['REQUEST_URI'].
Maar dat wil ik dus SEO-vriendelijk maken. Hoe zou ik die in het laatste voorbeeld moeten herschrijven dan?
Maar hoe moet ik dat concreet vormgeven in die onderste .htaccess. Dat krijg ik met geen mogelijkheid werkend.
Dat heb je niet nodig als je met een URL als site.nl/blah/2019 zou werken. Dan bouw je die segmenten (blah, 2019 etc..) op aan de hand van $_SERVER['REQUEST_URI'].
Mijn .htaccess ziet er in hoofdlijnen zo uit:
Code (php)
1
2
3
4
5
6
7
8
9
10
2
3
4
5
6
7
8
9
10
# Zet RewriteEngine aan
RewriteEngine on
# Werk vanuit de webroot, gebruik dan een /
RewriteBase /
# Stuur elke request door naar index.php
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ index.php [QSA]
RewriteEngine on
# Werk vanuit de webroot, gebruik dan een /
RewriteBase /
# Stuur elke request door naar index.php
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ index.php [QSA]
Gewijzigd op 08/03/2019 16:08:33 door - Ariën -
Maak vervolgens een index.php onder kalender met de volgende simpele inhoud:
Vervolgens kun je jouw kalender-directory aanroepen zoals je wilt:
http://www.domein.nl/kalender/het/maakt/niet/uit/wat/hierachter/komt
Dit komt allemaal bij jouw /kalender/index.php terecht, het pad begon immers met /kalender.
Jouw /kalender/index.php bepaalt wat er vervolgens met zo'n URL gebeurt:
#1 is dit een bestaande "pagina": toon de bijbehorende functionaliteit
#2 is dit een niet-bestaande "pagina": toon een 404-pagina
#1 en #2 programmeer je beide in /kalender/index.php, op grond van de inhoud van de aangeroepen URL (op te vragen via $_SERVER['REQUEST_URI']).
http://fangorn.thijma.nl/news/redirecting-all-requests-to-index-php-with-htaccess
EDIT: maar ja, daar staat wel uitgelegd hoe je hier makkelijk het pad uitvist, wat je verder kunt helpen om te bepalen wat er dient te gebeuren.
Gewijzigd op 08/03/2019 16:29:55 door Thomas van den Heuvel
Het bestand kalender.php staat in de WP-content map als thema en die wordt vervolgens gebruikt als pagina template met /kalender als permalink. En is dus de pagina website.com/kalender/index.php.
Code (php)
1
2
3
4
5
6
2
3
4
5
6
RewriteEngine On
RewriteBase /
RewriteRule ^kalender/index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . kalender/index.php [L]
RewriteBase /
RewriteRule ^kalender/index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . kalender/index.php [L]
Ik denk dat je het nu juist lastiger maakt doordat twee verschillende site in een enkele probeert te bouwen met beiden een aparte basis.
Gewijzigd op 08/03/2019 18:57:26 door - Ariën -
Code (php)
1
2
3
4
5
6
7
8
9
2
3
4
5
6
7
8
9
<?
get_header();
// Eigen invulling waarin in dit voorbeeld de kalender wordt opgehaald uit de database
get_footer();
?>
get_header();
// Eigen invulling waarin in dit voorbeeld de kalender wordt opgehaald uit de database
get_footer();
?>
Maar gebruik je dus aparte scripts buiten Wordpress zelf om in de Wordpress directory? Ook als je dingen uit de database ophaalt, behoor je dit niet in een template te doen, maar juist via een functie, en bij Wordpress is daar een add-on uitstekend voor geschikt.
Gewijzigd op 08/03/2019 19:29:03 door - Ariën -
Ik gebruik inderdaad eigen scripts daar tussen in. Het is vooral een databasewebsite waarbij ik dmv $_GET de parameters ophaal en die verwerk. Ik gebruik wel enkele plugins als een User plugin, Cookie en SSL bv. Maar ben daar niet echt fan van zolang het buiten Wordpress om kan.
Wat houdt je tegen om een add-on te schrijven?