Saturday, 19 November 2011

RedDot SEO (Part 1)

SEO is important for commercial websites and that's a given. As for local government (where I work) it has never been seen as quite so relevant. The rather blunt reasoning being that the public don't get a choice in which council they use, it's a captive audience so why bother? One thing is for certain, a users first view of your site (whatever its intended audience) is often not your homepage (therefore ignoring the exceptional navigation you have implemented), it's generally via search engine results.
This is where SEO can help us all; pointing the user in the right direction before they even step foot on your site. Anyway, enough of the waffle as I'm no doubt preaching to the converted here.

SEO and RedDot

I decided to revisit an area I expect every RedDotter has looked into at least once, that of enforcing unique & meaningful urls. The usual first part of this is easy enough - manually define publication packages with sensible directory names; all well and good, and usually done by some kind of RedDot admin so no worries about users getting in a pickle.
The second part is a bit more tricky, making sure published filenames are SEO friendly. There are already a couple of plugins available on the Solutions Exchange that will set page filenames to mirror the page headline but RedDot does not currently enable enforcement of unique filenames within a publication directory. Not an ideal situation and if a duplication occurs files are overwritten.

What process would we like RedDot to follow? Probably something like the following:

  • When a page is created or renamed, set the filename to a parsed version of it (no nasty characters etc.).
  • If a user manually sets a filename don't overwrite it with the page headline (unless the headline subsequently changes).
  • If there is a duplciate filename in existence; prompt the user for an alternative or suggest they change the headline to something more unique.
  • Don't let the user release the page if it contains a duplicate filename (ALA mandatory field warning).
  • Provide a SmartTree accessible toggle to disable the functionality for individual pages.



This is all possible with javascript and RQL and it's something I've been toying with the last couple of days. My main priorities for the solution:
  • Automated as much as possible; I don't want to bother the user unless really necessary.
  • As few RQL calls as possible within SmartEdit (Pure JS calls for any mandatory calls), I don't want the editing process slowed down.
So far I have been concentrating on embedding the processing in SmartEdit page-open.
I have the RQL down to one single mandatory call (I need the current filename and this is only available via RQL).


Impact on users

I am however, having some second thoughts on this approach. Maybe it should be done as part of the workflow process?

So what to do:
  • Stick with SmartEdit page processing which slows the editing process a little.
  • Let workflow do the file naming duplication checks and reject the page to an admin for fixing if required (but they won't thank me for the extra work).
  • As above but reject the page back to the user (unfortunately users hate workflow rejections and won't thank RedDot for not prompting them in SmartEdit before the released the page).
I think I'm going to stick with the SmartEdit option and finish off the implementation next week; I can always change tact at a later date if I think it's not really working.

Once completed, I will explain the RQL / JS in the second part of this post and (time allowing) post a newer version of the RustyLogic RedDotNet library with the backend code you will need if you want to follow the same approach.
Any thoughts on the subject more than welcome :)



  1. Whether you think you're preaching to the choir or not John, you've articulated your thoughts well, which will no doubt help lots of people and provide ideas to the product team.

    Many thanks,

  2. hey john

    whilst working at a previous agency, i built a similar plugin (actually based on your .NET framework) that would:

    -automatically assign a SEO friendly filename to the page when the page was first created. (i used a single placeholder flag in the page to check if a URL had already been assigned to the page or not).
    using the flag approach means that you dont have to execute a query to run a filename check each you access the page.

    - using the RQL command which returns back a list of filenames already used in the project, i was able to determine if a page filename already existed, and then automatically appended a version number to the filename.
    (I ignored publication packages.. just seemed like it would take a hell of a lot of RQL querys to get this to work)

    the performance on this search wasnt all that bad - just a second or two for a few thousand pages.. so considering that creating pages isnt as often as page updates, i thought it was reasonable enough.

    - ability to sync the filename to the headline, if the headline happened to change over time. Obviously this has SEO implications, however if your are able to handle 303 redirects automatically its not a problem.

    good luck


  3. @Danny: ta mate, see you on Wednesday :)

    @Kim: The RQL for dealing with the publication packages is actually quite easy. Will reveal more in my next post.

  4. Hi John,

    I created something similar, not sure if it would be of use.

    Regard the AJAX RQL, is it AJAX ASP or AJAX .NET? If .NET, does it require additional configuration other than putting the plugin into the plugins folder?



  5. Hi Jian,
    It's your plugin that got me thinking of this in the first place!
    I'm trying to go one stage further by detecting duplicates and monitoring any headline / filename changes. It's not in plugin form, it's AJAX RQL & AJAX .NET designed to sit in the background and not interact with the user.

  6. Hi John,
    Auto file name actually just does it quietly in the background as well. It does not have a form and do not require user interaction.

    However, it doesn't do checks for duplicate file name, perhaps your plugin can take the idea further. One must consider same file name, but different subfolder due to publication package and mapped path.

    Will the plugin just works by dropping it in or will I have to setup additional services/web application on the server?

    Looking forward to the next update!


Note: only a member of this blog may post a comment.