logo

Quick Follow-Up To My SEO Changes

It took a while but it now looks like the changes I made back in April, which aimed to improve this site's SEO, have kicked in and had a positive effect.

Change 1

The first change I made was to use a server-based Rule document to permanently redirect all domains to the same place. If you visit http://codestore.info you'll end up at http://www.codestore.net.

Whereas Google used to consider all the different (sub)domains as different sites, it now seems to consider them as one. Here's how the PageRank of each domain has been affected, according to whatsmypagerank.com:

Domain PageRank Before PageRank After
www.codestore.net 5 5
codestore.net 5 5
www.codestore.org 3 5
codestore.org 3 5
www.codestore.info 2 5
codestore.info 2 5

As you can see all sites now have the same PageRank. Unfortunately this hasn't (yet?) had the desired effect of increasing it from a 5 to a 6. The PageRank for this site used to be 6. Although I won't be losing any sleep over my PageRank.

Change 2

The other problem I tried to alleviate was that of "duplicate content". Consider the image below of a search illustrating how Google considered /store.nsf/ as a different page to the root / URL. Not good.

image

To rectify this I added a canonical link to all page. In the head of each page is now a meta tag like this:

<link rel="canonical" href="/store.nsf/" />

So, Google now knows that it should consider all the following pages as the same thing:

Again, this seems to have worked as, no matter what I search for now, I can't seem to get the same page to appear in the results more than once.

Summary

There you go. Two simple changes that have had an "immediate" effect on this site's SEO. If you have your own site or are responsible for others then why not make the changes too?

Only time will tell if the changes take the PageRank back up to 6. For now I'll just have to accept it as yet another sign that this site's not what it used to be ;-(

Comments

  1. I suspect the site is the same quality, it's just before there was probably a significant amount of 'invisible but for the web stats' people coming for Domino advice because that's what they needed in their practical work.

    I was one of them I suspect.

    Now, those people have probably drifted to other things and other sites based on their actual work.

      • avatar
      • Jake Howlett
      • Thu 17 Jun 2010 04:25 AM

      Number of visitors doesn't affect PR though, does it? It's all about the links.

      Show the rest of this thread

  2. Links within your site or links to your site? Not my strongest area SEO.

    If it's links to your site well that has to be a function of visitors in some way I'd have thought - though it might be impossible to put any numbers on it.

  3. Hi Jake, never knew the canonical link thing! I'm going to implement it straight into our website! Thanks.

  4. One of the things I've been experimenting with is using the server-based rules to eliminate the ".nsf" in the URLs. Here's an example of that. No matter what internal link you click on you'll never see the actual name of the Notes database.

    http://austincsl.org/

    It seems like you should be able to use the server-side rules to make the URLs canonical as well, although the your solution may be simpler.

  5. @Jake: The Canonical tag should be more like a last resort than an approach to fix dublicate content issues. The thing about relying on the Canonical tag is that you might not get the benefit of incomming links to the dublicate pages.

    So you should avoid public dublicate URLs in the first place.

    @RobShaver: Good approach eliminating the ".nsf" in the URLs, but why not take the full step? You got URL folders like /a/ or /nav/ in your web page URLs. As with the ".nsf" extension, it would be a lot better not to bother users with that kind of noice.

    Substitution documents can take care of that problem quite nicely, as seen here: www.e-conomic.com

      • avatar
      • Jake Howlett
      • Sun 20 Jun 2010 04:10 PM

      Hindsight is a wonderful thing Tue. If only I'd known way back when that one day I'd care about SEO then I'd not have registered anything other than codestore.net.

      However, the links are all out there now, pointing to different variations of the same URLs and unless I pain-stakingly hunt them all down I'll have to cater for that.

      On new sites I work on I always do try to avoid. For this site it's too late.

      Show the rest of this thread

    1. @Tue,

      I agree but that was the best I could muddle through to. It's been six months or so since I did that. I was trying to have the fewest rules I could manage. It was a trial and error process with a httpd restart each time I made a change.

      As I recall the only way I got figure out how to make it work was to have those intermediate targets like the fake view "a".

      Have you got any links to better documentation about how the rewrite works or how the wildcards work? Perhaps you could describe how you did it on e-conomics site.

      Thanks,

      Rob:-]

      Hide the rest of this thread

      1. I was in the same situation as you. Tried to find documentation and examples elsewhere to tell me how it could be done.

        I didn't find any, so I had to try myself. It took MANY http restarts to find a solution :-) Here is what I came up with:

        The substitution patterns in use on e-conomic's websites are tailored to make clean URLs for these URL structures:

        Section pages: domain.tld/section/

        Category pages: domain.tld/section/category/

        Subpages (1): domain.tld/section/page

        Subpages (2): domain.tld/section/category/page

        Notice how section pages and category pages ends with a '/' while subpages do not. This is how I want it because of usability, but it is possible to have all pages end with or without a '/'.

        Substitution patterns to make this work:

        Section level substitutions:

        /[section name]/* -> /[db path]/[db name]/[view name]/w-[page URL name]-*

        Category level substitutions:

        /[section name]/*/* -> /[db path]/[db name]/[view name]/w-[page URL name]-*-*

        View for looking up webpages:

        The view with the name [view name] got values in first column made of section name, category name and page URLs like this:

        Section pages: w-[section name]-

        Category pages: w-[section name]-[category name]-

        Subpages (1): w-[section name]-[page URL name]

        Subpages (2): w-[section name]-[category name]-[page URL name]

        Notice how the trailing '-' is used to determine if the page is a section/category page or a subpage.

        With this substitution pattern, only the section names needs to be put into substitution documents as absolute values. No big deal as most websites should only have a few sections anyway.

        The category names works dynamically and can be chosen/edited in the CMS.

        1. So I can understand and make it concrete using your web site. Each page in the DB has a "page URL name".

          The sections are each a separate page:

          - Accounting software

          - Support

          - Integration

          - References

          - News

          - About Us

          Under Accounting software there are some categories, which are also separate pages such as:

          - Functionality Overview

          - Security and Operations

          Beyond this there are what you call "page URL name". One entry under Security and Operations is:

          - e-conomic technical setup

          So does this mean that there has to be a separate rule for each section plus one for each category? Let me see if I can write a couple of substitution rules based on your patterns.

          For the section "Accounting software" the actual URL is:

          http://www.e-conomic.com/accountingsoftware/

          The substitution rule that applies is (I think):

          /[section name]/* -> /[db path]/[db name]/[view name]/w-[page URL name]-*

          Doing the substitution manually using "x" for the db path, "y.nsf" for the db name, "z" for the view name and "accountingsoftware" for the page URL name, we get:

          /x/y.nsf/z/w-accountingsoftware-

          Is that right?

          For http://www.e-conomic.com/accountingsoftware/security/ we would use this pattern:

          /[section name]/*/* -> /[db path]/[db name]/[view name]/w-[page URL name]-*-* and get

          /x/y.nsf/z/w-accountingsoftware-security-

          And finally for:

          http://www.e-conomic.com/accountingsoftware/security/technical-setup we would use the same pattern and get

          /x/y.nsf/z/w-accountingsoftware-security-technical-setup

          I think I've got it. Quite a nice solution except for having to create so many substitution rules. In my scheme I only had one level so I only needed one rule.

          Thanks ever so much. I'm going to have another go at this.

          Peace,

          Rob:-]

          1. Yes, you got it right. And I made a mistake listing the wrong subst. patterns. The correct ones are:

            Section level substitutions:

            /[section name]/* -> /[db path]/[db name]/[view name]/w-[section name]-*

            Category level substitutions:

            /[section name]/*/* -> /[db path]/[db name]/[view name]/w-[section name]-*-*

            Notice the 'w-[section name]' at the end. I mistakenly wrote 'w-[page URL name]' first.

            About the number of substitution docs: If you follow this pattern, you will need 2 substitution docs for each section on the website, but you don't need subst. for categories, as they are handled by the generic category level substitutions.

            So this is what is needed for each section name, fx. for the section 'accountingsoftware':

            /accountingsoftware/* -> /[db path]/[db name]/[view name]/w-accountingsoftware-*

            /accountingsoftware/*/* -> /[db path]/[db name]/[view name]/w-accountingsoftware-*-*

            On e-conomic websites there are about 6-7 section names, giving 12-14 subst. docs per website.

  6. Hi Jake,

    i've implemented it on our domino based website, but today I've been reading up on the following post, which shed a different light on the issue: http://www.seomoz.org/blog/complete-guide-to-rel-canonical-how-to-and-why-not

    Perhaps interesting for you to read.

Your Comments

Name:
E-mail:
(optional)
Website:
(optional)
Comment:


About This Page

Written by Jake Howlett on Thu 17 Jun 2010

Share This Page

# ( ) '

Comments

The most recent comments added:

Skip to the comments or add your own.

You can subscribe to an individual RSS feed of comments on this entry.

Let's Get Social


About This Website

CodeStore is all about web development. Concentrating on Lotus Domino, ASP.NET, Flex, SharePoint and all things internet.

Your host is Jake Howlett who runs his own web development company called Rockall Design and is always on the lookout for new and interesting work to do.

You can find me on Twitter and on Linked In.

Read more about this site »

More Content