Quick Follow-Up To My SEO Changes | Thu 17 Jun 2010 | Blog

Quick Follow-Up To My SEO ChangesThu 17 Jun 2010

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.

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

- Ian O'Rourke
- Thu 17 Jun 2010 04:19 AM
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.

Reply
1. - 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.
  
  Reply
  
  Show the rest of this thread
  1. - Jerry Carter
    - Thu 17 Jun 2010 07:54 AM
    Per "Growing your business with Google" (idiots guide to), page rank is a proprietary algorithm you (and the rest of us) are welcome to guess at.
    
    Reply
- Ian O'Rourke
- Thu 17 Jun 2010 05:07 AM
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.

Reply
- Ferdi Verlaan
- Thu 17 Jun 2010 09:20 AM
Hi Jake, never knew the canonical link thing! I'm going to implement it straight into our website! Thanks.

Reply
- RobShaver
- Fri 18 Jun 2010 01:45 PM
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.

Reply
- Tue Skaarup
- Sun 20 Jun 2010 09:55 AM
@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

Reply
1. - 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.
  
  Reply
  
  Show the rest of this thread
  1. - Tue Skaarup
    - Sun 20 Jun 2010 05:07 PM
    Hindsight is great :-)
    I understand the situation, many other websites have similar issues. But there are options, even if you have many backlinks pointing to DC pages:
    1) Like you made 301s from other Codestore domains to the www.codestore.net domain, do so for the pattern www.codestore.net/store.nsf*. Assuming ofc. you want www.codestore.net to be the homepage URL (recommended), otherwise the other way around.
    2) Make sure all internal links to your homepage goes to the correct URL, as Yahoo Site Explorer suggest you have many internal links pointing to both www.codestore.net and www.codestore.net/store.nsf/. It could be you already rectified this (I didn't check) and Yahoo Site Explorer just haven't figured it out yet.
    301s will transfer link value (as indicated by the visible Google Toolbar PageRank), but - propably - not 100%. Another drawback is the added round trip, making 301 pages slower. Still, 301s are the best option for situations like this.
    Btw., an annoying thing about the trailing "/" in Domino is that these 2 URLs:
    1) www.codestore.net/store.nsf
    2) www.codestore.net/store.nsf/
    - are technically different URLs, but Domino does not seem to care about the trailing slash at all. I have not managed to find suitable substitution/redirection documents to fix this issue.
    
    Reply
2. - RobShaver
  - Tue 22 Jun 2010 11:38 AM
  @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:-]
  
  Reply
  
  Show the rest of this thread
  1. - Tue Skaarup
    - Tue 22 Jun 2010 01:54 PM
    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.
    
    Reply
    1. - RobShaver
      - Tue 22 Jun 2010 03:43 PM
      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:-]
      
      Reply
      1. Tue Skaarup
        
        Tue 22 Jun 2010 04:00 PM
        
        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.
        
        Reply
- Ferdi Verlaan
- Thu 28 Oct 2010 02:16 AM
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.

Reply