CMS page lookup (301 | 404)???
Posted: Fri Jan 30, 2009 8:54 pm
So I'm busily working away on my own CMS and I reach the point where it's time to implement page lookup.
Obviously speed is a factor, so using PKID like I have in times past:
Would work awesome, unfortunately we live in a day and age (and I read enough forums, blogs, etc) where non-SEF URI's are seen as amaturish, so I need a way to construct (or let my users rather) SEF/SEO URI's from the page being displayed.
Some useful page fields:
- Title
- Alias
- Section
There are other fields, like keywords, etc, however they are potentially to verbose to be used for URIs.
If I cannot rely on a PKID, than my system must intelligently discover the PKID of a page given any number of URI parameters like the above.
Alternatively, I make the extension the PKID or something similar in the URI, that can be used as a direct lookup. The added bonus I see to using a PKID is that, in the case of a cache miss, the system would need to use the title or keywords and/or a combination of many fields to try and determine the PKID.
This is fine (although quite complex once I get above a few parameters -- I'm thinking a user plugin here would be best?) except that (unlike the PKID) the title and alias and other details can be changed by the user.
So what happens when the user updates their web pages and the URI's change from say:
To something a little more accurate as their content was updated to include more focus on SEO:
Now say, someone does a Google and finds the link to the above. They click the link, my system parses the URI and tries to find ONE page matching those keywords. Unfortunately the keywords/title/description/content has changed and the page is therefore not the only one to be returned.
Not strictly a bad thing, but had the URI included the PKID, then regardless of whether titles and meta data changed, clicking on an old link would have resulted in the user being redirected to the intended page, sorta -- albeit updated page.
So is it the same page?
Perhaps the best way to address this issue to keep an interal log of pages which have had their URI/permalinks changed and store the translation in a lookup table and use that to find pages which have moved...
I suppose this requires asking some SEO questions...liek which affects rankings more:
1. Having old URI redirect to a new URI and send 301
2. Having old URI show as "Page not found" and send 404 with a listing of article links which are suitable matches
WHat do you think?
Lastly, I suppose I could implement a admin feature where the user entered their permalink manually (like WordPress) and once created cannot be changed, and if it is, then record a redirect in an .htaccess file or something?
Cheers,
Alex
Obviously speed is a factor, so using PKID like I have in times past:
Code: Select all
index.php?pageid=12Some useful page fields:
- Title
- Alias
- Section
There are other fields, like keywords, etc, however they are potentially to verbose to be used for URIs.
If I cannot rely on a PKID, than my system must intelligently discover the PKID of a page given any number of URI parameters like the above.
Alternatively, I make the extension the PKID or something similar in the URI, that can be used as a direct lookup. The added bonus I see to using a PKID is that, in the case of a cache miss, the system would need to use the title or keywords and/or a combination of many fields to try and determine the PKID.
This is fine (although quite complex once I get above a few parameters -- I'm thinking a user plugin here would be best?) except that (unlike the PKID) the title and alias and other details can be changed by the user.
So what happens when the user updates their web pages and the URI's change from say:
Code: Select all
domain.com/articles/101-web-marketing-best-practices.htmlCode: Select all
domain.com/articles/internet-marketing-seo-best-practices.htmlNot strictly a bad thing, but had the URI included the PKID, then regardless of whether titles and meta data changed, clicking on an old link would have resulted in the user being redirected to the intended page, sorta -- albeit updated page.
So is it the same page?
Perhaps the best way to address this issue to keep an interal log of pages which have had their URI/permalinks changed and store the translation in a lookup table and use that to find pages which have moved...
I suppose this requires asking some SEO questions...liek which affects rankings more:
1. Having old URI redirect to a new URI and send 301
2. Having old URI show as "Page not found" and send 404 with a listing of article links which are suitable matches
WHat do you think?
Lastly, I suppose I could implement a admin feature where the user entered their permalink manually (like WordPress) and once created cannot be changed, and if it is, then record a redirect in an .htaccess file or something?
Cheers,
Alex