Getting First Page Search Results with WordPress

Posted on April 12th, 2011 in Search Engines by Russ

I saw this in Craigslist today:

(snip)
I am increasingly asked to design WordPress websites, and asked to make them so they are easily findable on the first pages of a major search engine like Google, Yahoo, Bing, etc. In fact, just today, I got an inquiry on this very matter. The client wants me to redesign their existing website using WordPress, so I can show them how to update and maintain it, AND they want people to be able to find the website on the first pages of a major search engine. …Two weeks ago, was the last inquiry I got on this very matter, so there is potential for work on 1 or 2 websites a month, if I can resolve this, potentially. …I would love to partner with a mentor webmaster who could either take on that end of the websites or could instruct me. I’m open, and would like to resolve this ASAP. …HELP ME!!!!
(some more snipped)

I’m not a SEO guy; I’m a web programmer (among other things) with some ideas about SEO.

I didn’t send them an email offering my elite services as a SEO guy to help them get first page results. I started off by pointing out that the first thing they needed to decide was the keywords they wanted to rank for– and that “camera lenses” would be a lot harder to rank for than “used canon lenses in Portland.” So the first step would be to define some better keywords.

And for on page SEO, frankly, you could do worse than WordPress- that is, with some SEO plugins, good choices of keywords, pretty URLs, you know, all that stuff a good webmaster would set up for you.

However, you also need to look at the kinds of content you have, the quantity and quality of links to your site and even the responsiveness of your web server.

In a handful of nutshells, you need quality posts that are over 300 words long, using but not overusing your keywords. They should be the kinds of posts that people who search for what you’re offering are looking for, helpful or interesting, or whatever.

You need “some” links. You can’t have an exact number because it’s not an exact science. If they’re all from hack blogs, you might need thousands of them. If they’re from solid domains with some personal accountability, you might need hundreds. But don’t run out and buy them all in one bunch, you want them to be gradually built up.

And starting last year, Google started factoring in the response time of your server; a more responsive server gets better results. Pages loading in a couple of seconds get better results than pages that take a minute to load.

However, keep in mind that none of these are really solid rules; they are differently weighted tests that you could consider as you go through a SEO offering. To add to that, Google (and probably Yahoo and Bing, but they’re less well publicized) changes its ranking algorithmic about once a year. So you might find that your carefully tweaked and optimized WordPress site sits at number seven for three months and suddenly slides to thirty three, and there were no changes.

What I try to tell people (but I believe most people don’t hear me) is that the search engines are trying to help people find stuff. They’re not “screwing the webmasters” or “being completely obtuse” or even “gaming the systems.” Search engines want to be used to find stuff. So make your stuff easy to find and worth finding, let the search engines do their dances, and just do your best in terms of making quality stuff.

All that being said, if you need a good Search Engine guy, talk to my friend Chris Bigler. I’ll post his email or something when I have it (should be Real Soon Now).

Your Mobile Code

Posted on April 7th, 2011 in mobile websites by Russ

Hand crafting your site’s HTML for the best mobile experience can be a real pain in the neck.

Mobile Moxie’s Page Code Grader can help lighten that burden. It’s pretty straightforward to use; put in your site’s URL and pick a user-agent, and then their script will get the site and run a bunch of checks on it. They have a bunch of different UserAgents paired with the page layout images so you can get a rough idea of how your inspected page would look on that device.

Like most tests on the web, however, you should take this test as a guide and not as a rule. When I ran this test on a mobile site, I was surprised to get dinged for the use of tables (this particular site doesn’t use tables) and dinged for style tags (this particular site might have style tags, but I don’t think so). And I’m not sure how to get a 1 pixel border without specifying the border width in pixels.

However, there were some good things it caught; it steered me toward the use of handheld.css (as opposed to the style.css file I normally use; apparently the name is important) and it reminded me to use relative measures rather than the absolutes I had previously (I had a line height of 24 pixels, and changed it to 2em). It correctly found that my images are nice and small. It liked my text-buttons (as opposed to some unwieldy image buttons).

Overall, I give this tool a B. It’s in my list of tests to run, but it’s not the last one I’d use.

If you’re having a problem with your image sizes, give Dink a try: Dink does resizing of images for mobile devices, on the fly, so you don’t have to. And it has drupal and ruby on rails plugins.

Rails form skipping auth token from a specific form

Posted on April 4th, 2011 in Ruby on Rails by Russ

This might have been solved more elegantly or more securely. But it’s here if you want a place to start.

I have a client using Rails, and they want to log into their site from another site (another domain). The problem is that RoR uses “authentication tokens” for any POST, PUT or DELETE HTTP requests; so any form that does a POST action requires this code. It’s supposed to be a non-predictable code that the server can assign and check for on the return, to make sure the session’s valid. The login form is a POST form. Thus, the site needed an authentication token. Or it needed to ignore that for this other domain.

The solution I came up with was to use a ‘skip_before_filter’ in the sessions_controller.rb file. It looks like this:

skip_before_filter :verify_authenticity_token, :if => Proc.new {|c| c.request.referer =~ /otherdomain/ }

It’s not elegant and could be thwarted by the referrer looking like “http://example.com?attack_vector=otherdomain” but I think by the time someone is hand crafting referer strings or setting up forms, there will be other issues to deal with (firewalls, password strength, et cetera).