Time for a little rant.

I’ve been researching Google’s initiative to crack-down on websites selling and buying paid links. I’ve let myself get a bit riled-up as I’ve re-discovered the following:

1. Too many people still think Capitalism is somehow inherently evil
2. Some usually bright people have an amazingly hard time distinguishing between spam and good content

I’m not going to spend a lot of time on why Capitalism is not inherently bad. Go read Mike Mann’s book on making change—it’s a free book (making it appealing even to anti-capitalists).

On point number two I’ll voice a few more thoughts. Aaron Wall wrote an insightful post on new link strategies that people have employed to avoid having to purchase links outright. Some of the comments to that post just about killed me.

One comment reads, “It can’t be long until Google starts detecting these types of strategies.” An astute retort followed shortly, “Never going to happen. What is there to detect? Good content written by an author who writes about the field? Sorry, writing guest posts/content is as legitimate as it gets.”

After reading so many on similar blog posts, I got the feeling that there are many people out there who must have been bitten so many times by the spam bug that they can no longer see the difference between junk and good content.

What do people expect? Should Google be penalizing online newspapers because their journalists get paid to produce the content? Should Google ban their own site for offering up paid listings?

I think some people have this idea that any website actively trying to get links, traffic, or any other type of attention is spam, or at least in the same category. They think that any site attempting to draw traffic must be doing so surreptitiously, or behind some clandestine operation. No so! These are surely the same people who think Wikipedia would turn to the dark side by posting ads on the site. I’ve got news for you people; most of the sites you read that have content worth reading exist because someone is getting paid (refer to the link to Mike Mann’s book above).

The difference between spam and good content lies in context and relevance—two things that these spam crying scuttlebutts should be able to determine. Google doesn’t claim any artificial intelligence and they seem to be able to do a good job most of the time.

Don’t get me wrong, I hate spam too. But you need to know the difference. Here is a very succinct and simple way to distinguish spam from quality content for those of you who have a hard time telling he difference: spam will always appear unsolicited and out of context. Both attributes must accompany any content for it to be categorized as spam. If you have a site that has relevant content about a particular subject and it is accompanied by pertinent ads, you are not looking at spam. Read this entry by Matt Cutts for other good insights.

Beware of Spammers in Capitalist's Clothing is a post by SEO expert Peter Ehat. For information about our SEO services or more great SEO tips and tricks, visit the SEO.com blog.

Hey, Marty, would you mind parking the DeLorean for me while I finish up this blog post? Thanks.

Hi, everyone! I’ve just come back from the future. Well, not really. I’ve actually just been reading through a bunch of articles about the Semantic Web as envisioned by Tim Berners-Lee and other brilliant thinkers. My appetite to research this topic was spurred by this article I read about two weeks ago. It’s been a fun escape into the world-of-tomorrow. Some have already assigned the moniker “Web 3.0″ to the Semantic Web. Here we go again…

So did I find anything of value on my futuristic escapade? Well, I started my trip (as always) by going to see The Oracle to find out what she thinks of the Semantic Web. It’s still unclear to me how people will interact with such a system—from what I can tell there are no consumer apps yet that handle these types of semantic web interactions. But according to the Wikipedia article, computers will do most of the menial pairing of search results that we currently do manually.

Funny enough, there are many who believe that this particular vision of the future cannot come to fruition. Others say it has already begun to happen. I don’t know enough about it yet to base an opinion either way, but I do see elements of a semantic web in now widely used web techniques like tagging.

According to Tim Berners-Lee, Google will not survive on the semantic web—at least not in its current state. Yahoo even recently announced that they will begin supporting certain semantic web standards and technologies to let people produce much richer search results.

So if search engines as we know them need to change at the advent of this new Semantic Web, do SEOers need to follow suit? Will SEO become the task of simply building properly formatted semantic markup for digestion by future search engines? That could be part of it. In fact, part of good SEO practices now include creation of semantic based data feeds (think RSS). And now with the birth of Yahoo’s open search, website owners will be rewarded for producing more semantic data and suppling it to Yahoo. I expect Google has something similar in the works.

But how far out is our paradigm shift? How quickly will the bandwagon pass? Is there a bandwagon at all? The more you think about it, the more you think, “wow, this Web 3.0 is going to be pretty cool! It’ll make SEO and search in general a lot cleaner”. As I began to ponder all of these new ideas, The Oracle sent me to this other article. Stopped in my tracks.

Mr. Doctorow is right on. One of the huge problems Google et al currently face is the overabundance of garbage on the web. This must be what Berners-Lee meant in part when he said, “…make sure people aren’t using their authority to do things that they shouldn’t be doing”. Unfortunately, that’s much easier said than done. There will always be people who are trying to game the system. Website owners of the future will be creating oodles of inaccurate meta-data about their spam sites to trick your computer into pulling bogus information into your data mash-up. Can you imagine searching for a good Italian restaurant near the place you have a meeting tomorrow at noon and you’re given a map full of bogus locations all advertising male enhancement pills. No thanks.

Let’s get back to the original question quickly: does SEO die on the semantic web? I think the answer is a resounding no. In fact, an understanding of keywords, search engines, markup, and semantics will play an even bigger role as time goes on. But who knows what the real future will bring.

Alright, I’m outta here. Where I’m going I don’t need—roads. But I do need to add some quick semantic metadata to this post before signing off (*throws in another old can and a banana peel*). OK, I’m off!

Does SEO Die on Web 3.0? is a post by SEO expert Peter Ehat. For information about our SEO services or more great SEO tips and tricks, visit the SEO.com blog.

When Building Your Site

A few of us here at SEO.com are big Apple fans. The much anticipated announcement today that the iPhone SDK would be released propels the iPhone into competition with a variety of other handheld devices for business and gaming, and publicizes a few interesting facts about mobile web browsing.

Apparently the iPhone is the most widely used mobile device for browsing web pages, consuming 71% of all web pages accessed by mobile devices. Yes, the iPhone does present the web as you would see it from your desktop or laptop computers, but a few considerations will be forefront in the minds of developers as the iPhone continues to gobble up market share. To name a few:

Use of Flash
Steve Jobs makes it sound like he has no immediate intention of making the iPhone and Flash Player compatible. You may want to look at your site and make sure you don’t have essential pieces done in flash–or that you have iPhone detection and replacement of flash content. For example, Google Analytics uses flash to display graphs and other data. It’d be nice to have some sort of replacement instead of a question mark in the spot of the embedded swf.

Accessibility
You should always make your sites as accessible as possible (for SEO purposes and otherwise). I know, the iPhone shows pages like your computer does, so you don’t think paying special attention to the iPhone is important. But remember, the screen they’re looking through is much smaller. I personally like to see the sites I visit on my iPhone without “special” formatting. However, it may be the case that some charts, graphics or features may need an iPhone friendly interface, either for faster user interaction, or better visibility.

I’m sure a myriad of things will begin to surface as site owners continue to see iPhone agent strings in their stats. Feel free to comment on what other influences you think the iPhone will or will not have on the way web pages are built and delivered.

P.S. The iPhone user agent string is:
Mozilla/5.0 (iPhone; U; CPU like Mac OS X; en) AppleWebKit/420+ (KHTML, like Gecko) Version/3.0 Mobile/1A543 Safari/419.3

Consider the iPhone is a post by SEO expert Peter Ehat. For information about our SEO services or more great SEO tips and tricks, visit the SEO.com blog.

What To Do With Your 404 Errors

Part 2 of the SEO for PHP Series

Blast! I’m late for my Nunchucks class and I can’t find my keys! I was pretty sure I left them right here by my laptop. Ah ha, there they are—glad I finally found them. Good thing I did, ’cause I need the practice. Check me out at last week’s class.

Don’t you hate it when stuff gets lost? I sure do. When you’re sure that something is there and then all of the sudden, 404! It’d be helpful to have a little 404 post-it note show up on my shelf when my wallet is not in its place. Or, when sitting down to dinner I’d see a big foam 404 cutout where my son should be but is instead still outside playing.

Well, as much as it bugs you, it’s probably just as bad for your site’s visitors to find a link somewhere in a search engine or blog, and come to your site just to get zinged by a big 404 message (the system is down, yo!).

Even cooler than the 404 post-it notes would be little 302 messages, with detailed information pointing me to where the object of my search hides. I can see it now, “302: Keys temporarily moved between the couch cushions.” Of course, you never really see 302 messages on the web, but it would be nice in real life.

So why not equip your site with a clever little something to take care of any misplaced pages? You may even go as far as to write a little script (or borrow the one I’ll include here) to transform those 404s into 301s and get your users back on the road again. Here’s the process I’d follow:

1. Get yourself a Google account and add your site to your webmaster tools if you haven’t already.
2. Make a list of 404 errors that your users have come across on your site.
• Find out what 404 errors Google has found (look through your webmaster tools).
• Look in your server logs for other 404 errors.
3. Search through search engine results for problem pages.
4. Create a PHP “map” page (essentially an array of missing pages and their new locations).
5. Add a small piece of code before all other code processed on your site to handle redirects.

*A quick side note: right in the middle of typing this entry, I found Nelson’s enormous water jug here in my office—must have been left here sometime today. I just sent it back to him with a friendly 302 post-it note attached “302 Redirect: The water jug you’ve been looking for was temporarily moved to Peter’s office”. Wow, these notes are sure helpful! I need to get a patent attorney on the phone quick! Alright, back to the post…

Remember that not all the 404 messages that are dished out on your server need to be redirected. Some of them are legitimate status codes for pages people have requested that you really don’t have on your site. So sift through and create your list of only the pages you want people to still be able to find. Once you’ve identified these pages, organize them into an array map list like so (I’ve created a file called redir_map.php):

$redir_map_arr = array(
  'productsconnect.htm' => 'products',
  'press-releases/press-main.htm' => 'news/press-releases',
  'current-news/news-main.htm' => 'news'
);

OK, I’ve only got 3 pages to redirect here in this example, but it should still be pretty fun. Save the redir_map.php file somewhere that makes sense on your site. Now on to the implementation.

Depending on the type of structure you have on your site for delivering pages, you’ll have to find a way to include this little redirection map before ANYTHING else on your site is processed. This is very important because we’re going to send some HTTP status codes to the agents requesting pages on our site. If you’ve already sent headers, you’re likely going to run into problems.

I personally like to build sites to redirect all incoming traffic to the index.php page (done using an .htaccess file and explained in a future blog entry). This keeps my sites DRY–I don’t have to put includes on every page for a header and footer and what not. So I put the following PHP code in my index page before just about everything else (you’ll have to determine where to put this script on your own site—just ensure it is the very first piece of code on your site that sends headers):

require("redir_map.php");
foreach ($redir_map_arr as $old_url => $map_to){
  if(strpos($_SERVER['REQUEST_URI'], $old_url)){
    header( "HTTP/1.1 301 Moved Permanently" );
    $host  = $_SERVER['HTTP_HOST'];
    $uri   = rtrim(dirname($_SERVER['PHP_SELF']), '/\');
    $query = ($_SERVER['REDIRECT_QUERY_STRING']) ? '?'.$_SERVER['REDIRECT_QUERY_STRING'] : NULL ;
    header("Location: http://$host$uri/$map_to/$query");
    exit;
  }
}

Alright, as you can see, I’m requiring the redir_map.php file we created previously. I then loop through each name value pair in the array (the key as $old_url and the value as $map_to). Then I look for the page that’s being requested by the incoming agent, and see if it matches something in my list. You could write a regular expression for more sophisticated matching, but this works for simple stuff.

Then comes the meat of this operation. The first thing I’m going to do is send a header telling the agent that the file it’s requesting has been moved permanently. This way, Google, Yahoo et al will make sure to index the correct page, leaving the old reference url alone.

The $host, $uri and $query variables should be obvious (see exception below). After setting those, I simply redirect the request to the new location using the PHP header function again.

Last, I exit out of PHP execution. You’ll want to do this just to make sure your script doesn’t continue on with whatever it would have done had you not just redirected your visitor to the new place.

That’s it! I’m going to leave comments open on this to see what other ideas others may have, or see what others have done for this same problem. Thanks everyone—and keep an eye on those keys and water-jugs!

*Note: The script I’m using passes on any queries that may have been in the old URL. Some people have directives in thier .htaccess files that may conflict with what the script does here. If you run into problems, just comment out line 7 in the example above, and remove /$query from the header location string on line 8.

Handling 301 Redirects with PHP is a post by SEO expert Peter Ehat. For information about our SEO services or more great SEO tips and tricks, visit the SEO.com blog.

Part 1 of the SEO for PHP Series

Finally, an article that will explain the problem and answer the question that has perplexed and eluded web developers and SEO experts for years. The question: How do I get my PHP pages indexed on Google and other search engines?

The Myth Exposed

First, I need to point out that there has always been a myth surrounding Google’s indexing (or non-indexing) of PHP pages, specifically dynamically generated pages. I suppose my mysterious title to this entry doesn’t help the matter, because Google is easily able to index both dynamically generated PHP pages and PHP pages with dynamically generated content (read further down for an explanation). There are some good practices that webmasters should follow to make sure their site’s pages are clearly readable, but there’s not really a big mystery. I’ll explain in later posts in this series how you can make your PHP site Google ready. In the mean time, Google (as always) is smart enough to sort through most of the garbage that people sometimes post to the web. So why write an article you ask? Because there are so many people who still believe this myth, and it’s about time someone pointed out that Google has already set the record straight.

It’s easy to see how such a myth could be perpetuated over time. Google did have an excerpt from their Webmaster Guide back in 2006 that said Google had a more difficult time indexing pages with a query string in the URL (for those of you not familiar with URL parts, read this entry by Google’s Matt Cutts). Google once warned:

“Don’t use “&id=” as a parameter in your URLs, as we don’t include these pages in our index.”

Ah ha! The spark that started the fire. So, Google really did have a hard time at some point indexing PHP pages? Well, not so fast Mr. or Ms. Webmaster pants. They didn’t say anything about dynamically generated pages, or even PHP for that matter. They simply said it’s best not to use certain query strings in your URLs. It has been exaggerated and expanded over the years to somehow include the idea that Google is wholly incapable of indexing pages processed by PHP. This notion was false then, and is false now. In fact, Google has now even removed that line from the Webmaster Guide and has stated clearly that it’s OK to have dynamically generated pages.

People who actually still believe that PHP cannot be indexed by Google have obviously never performed this query:

inurl: .php

What? That’s an outrage! Google doesn’t index PHP pages! Especially not that first one that is dynamically generated and contains “?id=” in the query string! OK, now I’ll remove my tongue from my cheek so I can finish up here.

A Technical Explanation

Alright, here’s where we’ve got to get a little technical. Don’t be afraid, it’s not too bad. After all, it was the people who weren’t willing to explore a little bit of the technical stuff that perpetuated this myth in the first place. Be a part of the solution and keep reading!

First, there is a real difference between dynamically generated pages and pages with dynamically generated content. It is often the case that dynamically generated pages will also have dynamically generated content, but not all pages with dynamically generated content have to be themselves dynamically generated. Confused? Let me explain.

Pages With Dynamic Content

Let’s say I have a file called faqs.php that actually takes up memory on my server, and contains PHP code that performs a certain function. Maybe the code accesses a database, obtains a list of FAQs, and prints them out to the screen. This is an example of a non-dynamically generated page that dynamically generates content. In this case, the faqs.php script is only going to consistently deliver FAQs to the user. It will probably never show a terms of use, contact, or about page. It’s for FAQs.

Google has never had a problem indexing these types of pages, even though they are created using PHP. The fact that PHP is involved is a moot point because all the content has been delivered to the browser or search engine spider after the content was compiled together on the server. The spiders don’t care what happens behind the scenes to deliver my page, especially when I have this simple URL: http://www.mysite.com/faqs.php. For all intents and purposes, this page is the exact same thing as a static HTML page delivered from the server to the spider or browser (the only difference is the .php extension in the filename). Even the file extension is a non-issue considering the fact that a webmaster can setup Apache to execute and deliver PHP pages with the .html extension, which would totally mask the fact that the page content has been delivered dynamically.

Dynamically Generated Pages

Now, let’s imagine I have a file called index.php, and it has a query string appended to it so it looks like this: index.php?page=faqs. This script might be producing what people would call a dynamically generated page. It too, in this case, delivers content to the screen, also showing information about FAQs, just like our previous example. The difference with this index.php page is that it’s probably not specific to just FAQs. It’s probably also used to deliver the terms of use, contact us, and about pages respectively. In theory (but not in good practice), you could have an entire website of thousands of pages that come from one single PHP script.

These are the types of pages that Google has warned about in the past. While they’ve never had problems with the types of pages described previously, you can see how Google may have had a hard time in the past, or just simply refused to keep track of and index these types of pages, especially if multiple name value pairs exist in the query string.

Short and Simple Answers

OK, your head may be spinning after all that rigmarole. Let’s look at how Google themselves answers the question: “Does Google index dynamic pages?” The short and simple answer is yes.

Well, would you look at that! Google themselves set the record straight once and for all. I don’t necessarily like their suggestion of making static pages with the same content as your dynamic pages (if that was an option there’d be little reason to use dynamic pages in the first place). Regardless, Google essentially says to all you wild and wacky webmasters with equally wacky URLs, “Go ahead and make them dynamic pages! We’ll round-up and corral your content free of charge.”

So Google has caught up to the Wild Wild Web in this regard—and they’ve done so just as a new frontier is emerging. One of pretty URLs and simple-to-index PHP sites and pages. One where dynamic pages and dynamic content are still the staple, but with a new 2.0 friendly flare. Check back soon for the next article where I’ll explain how to create a simple PHP site that implements some of these newfangled things, and employs some suggestions from Google Webmaster Central.

How to Get Your PHP Pages Indexed on Google is a post by SEO expert Peter Ehat. For information about our SEO services or more great SEO tips and tricks, visit the SEO.com blog.