Nothing is worse than having to build around a messy site. What I mean by messy is lengthy URLS with pointless characters and crazy dynamic URLs! So here are my tips on creating an SEO-friendly site:

1) Use static URLs when possible. This might not be possible with really large sites, but if your site has less than 50 pages and doesn’t require new pages to be created all the time, this is definitely the way to go. This is definitely the easiest way and best for SEO. The second best is using an htaccess redirect to use a name in the URL and pass it as a GET variable. Something like this:

http://www.tampacreations.com/portfolio

In this case, portfolio is being passed as a GET variable, and you should always check this against an array of acceptable values! Combine that htaccess code with the proper rewrite condition to tack on the www, and handle forward slashes at the end too. Would you like to see it? Here’s the code I’m using:

Options -Indexes
RewriteEngine On
RewriteCond %{HTTP_HOST} !^www\.yourdomain\.com$ [NC]
RewriteRule ^(.+)/$ http://www.yourdomain.com/$1 [R=301,L]
RewriteCond %{HTTP_HOST} ^(www.)?yourdomain\.com$ [NC]
RewriteRule ^(.+)/$ http://www.yourdomain.com/$1 [R=301,L]
RewriteCond %{HTTP_HOST} !^www\.yourdomain\.com$ [NC]
RewriteRule ^(.*)$ http://www.yourdomain.com/$1 [R=301,L]
RewriteRule ^([^/\.]+)/?$ index.php?page=$1 [L]

So that’s the second best option if you have to go with dynamic URLs and it works pretty well! I believe I’m using PHP, then, to set 404 status of not found domains.

2) Search Pages can be a nightmare! Search pages can be problematic because they’re dynamic by nature and can end up having lots of variables in them. I think the trick here is to have a few of them indexed (the simple ones) and list those in your sitemap. The other ones you can let Google figure out or just deny it access.

3) Watch out for capitalization! Capitalization counts in URLs (just not the domain), so if I were to have a page Portfolio.html and portfolio.html, those are two different pages! If you’re using dynamic URLs, this can become a big problem with duplicate content.

4) Multiple websites. Lot of e-commerce site owners have the mentality that duplicating their entire store 5 times and putting it on 5 different domains helps their SEO out. Probably not a good idea. What ends up happening is since most stores have a lot of products, the owners use the same descriptions, same images, everything, and all the sites end up having duplicated content issues! I happy to report that a client I worked with who had this issue across 4 domains, downsized to one domain, and has twice as much traffic now after doing so in about 12 months. It takes time, but it’s worth it. The only way you should keep 5 different stores is if all the stores are different! Different product titles, different descriptions for each page, keywords, product descriptions, shipping text, contact text, etc. etc. etc. Everything should be completely different if you want to rank well.

\r\n

This is a line break, right? Well it can be. It depends on if it’s processed as normal text or not.

Let’s say a user is submitting a form and in the textarea, they add some line breaks. Let’s say they miss a field and  you have the form printing out it’s own POST values (so they don’t accidentally lose anything), like this:

<textarea cols="32" rows="6" name="description"><?=$_POST['description'];?></textarea>

This is pretty simple, it’s just printing out the value of the posted description variable. But like I said a minute ago, if they had put line breaks in their textarea, their information will be posted in the textarea again, but it will look like this:

Information on Line 1\r\nInformation on Line 2

The problem here is that the \r\n is getting changed to normal text. To change it back, we replace it with itself, but with double quotes, returning it back to code as opposed to normal text. Here’s the final result:

<textarea name="description" rows="6" cols="32"><?=str_replace('\r\n',"\r\n",$_POST['description']);?></textarea>

For our purposes, we’ll pretend your audience is strictly within the United States. The next step then is to think about what the main goal of your website is and how the colors will help reflect the attitude your website needs to achieve its goals. Here are some examples of associations:

1. Saturated colors are good for youth related items, and semi-saturated for fun, exhilarating, etc.
2. Pastel colors signify peace, relaxation, etc.
3. Dark colors can be good for evil, secret, technological, etc.

You also have some specific colors with some overall associations. Not to say they’re specific to these in particular, but they work well for what they’re paired with:

1. Royal/Dark Blue is typically associated with corporate.
2. Red associated with extreme
3. White associated with large/enterprise
4. Green associated with eccentric

These are just some examples. To find more, visit popular websites and see what they’re using to influence the vibe of their visitors. Influcing a vibe can be very helpful in raising conversions and accomplishing goals so when you’re thinking about your next color scheme for your website, be sure to put some extra thought and research into it instead of just going with your favorite color (pink).

Now a little tip for users, most websites use sessions to keep you logged in, and in most cases you can use your browser’s back button to go back to the original page you requested before it redirected you and refresh that page, and you’re there. But it shouldn’t have to be that way. If you’re a developer, you need to think ahead in your coding and login script. You’ll need to implement some way of redirecting the user to the protected page that they originally requested after they login. This is easier said than done sometimes, especially if your script is already written.

Some extra tools to use here if you’re in a tight spot for coding: Cookies and Header Redirects. Let’s say you’re script is already written… it looks something like this:

1. Person clicks on link to a protected page on the site, requesting the protected page
2. You have some code that either forwards them to a login page or displays a login page
3. The login and it automatically goes to/displays a main account page.

It can be tough to implement and carry variables over these pages and between files, so storing and passing the initially requested URL can be difficult. Although, using Cookies can work pretty well. The basic idea is to interrupt the second step. When the code is forwarding them to a login page/content, it’ll first check to see what the URL is and store it as a Cookie variable. Then when they are logging in, before it sends them off to the main account page, we can check that Cookie to see if it’s set and what’s in there. It would be smart to compare that value to an array of allowed values and forward them to the necessary page/content afterwards, if it matches something in your control array. To store that URL, I would use a regular expression to grab the page name and since it’s likely that some of your protected pages will have GET vars attached, take those variables and store them in a separate cookie, later appending them if the page matches what’s in your control array. You shouldn’t really need to deal with POST variables between a non-protected and a protected requested URL.

Usually found at the bottom of sites like Google and eBay. There’s two pieces of data we need:

1. Start At / Offset Value (usually set in the URL)
2. Limit (set internally or in the URL)

Being we only need these two variables, you might think this is a pretty simple task, but creating some well-working links takes a fair bit of code. For this example, we’ll define the limit internally, but still use dynamic code so it could be used as a GET variable.

The first issue we have in defining links to a different offset is in the URL itself:

index.php?keywords=tampawebsitedesign&start_at=10&order_by=1

As you can see here, our start_at variable is equal to 10, which is what we’ll put in our sql string. The problem is when they hit the next page button that sets it to 20. This impacts your links because you have to securely redefine the offset variable without loosing the other variables. Here’s how we would do that:

// get the current URL
$current_url = (!empty($_SERVER['HTTPS'])) ? "https://".$_SERVER['SERVER_NAME'].$_SERVER['REQUEST_URI'] : "http://".$_SERVER['SERVER_NAME'].$_SERVER['REQUEST_URI'];
// replace the start_at variable and value
$pattern = '/\&start_at=[0-9]*/';
$back_forward_url = preg_replace($pattern,'',$current_url);

Here we’ve basically stripped our start_at variable and value from the URL. Moving forward, we need to generate our Next and Previous buttons. This part is pretty simple:

$start_at = $_GET['start_at']; // set the start_at variable equal to the URL value
$limit_num = 10; // set the limit equal to 10 (or whatever you want)
 
// calculate the previous amount and link
$previous_amt = $start_at - $limit_num;
$previous_link = '<a href="'.$back_forward_url.'&start_at='.$previous_amt.'">Previous</a>';
 
// calculate the next amount and link 
$next_amt = $start_at + $limit_num;
$next_link = '<a href="'.$back_forward_url.'&start_at='.$next_amt.'">Next</a>';
 
// if statements which set the links equal to nothing
if ($start_at == '0')
{
	$previous_link = '';
}
if (($start_at + $limit_num) >= $total_results)
{
	$next_link = '';
}

At this point we have our Next and Previous button variables taken care of. Now we need to make the numbers in the middle. Something to note, however, is that if you have 100 pages of results returned, we don’t want to print out 100 numbers, we only want to print out 9 or 10 or around there. So we need to install a range of if statements that will make sure we put in the right amount.

The first step is to create a function which our total pages and current page can calculate from:

// shared function for calculations
function find_page($tr,$ln)
{
	$pages_total = intval($tr / $ln) +1; // intval rounds any decimal down to its integer value
	$match_results = ($pages_total -1) * $ln;
	if ($match_results == $tr) {$pages_total--; }
	return $pages_total;
}
// find total pages
$pages_total = find_page($total_results,$limit_num);
 
// find current page
$curr_page = find_page($start_at,$limit_num) + 1;

Next, we put in our if statements to set two new variables: $page_link and $loop.

 
if ($pages_total < 9)
{
	$page_link = 1;
	$loop = $pages_total + 1;
}
else if ($curr_page + 4 > $pages_total)
{
	$page_link = $pages_total - 8;
	$loop = 10;
}
else 
{
	if ($curr_page < 9)
	{
		$page_link = 1;
		$loop = 10;
	}
	else 
	{
		$page_link = $curr_page - 4;
		$loop = 10;
	}
}

Just about done! Now, we’ll loop through and save our links to a variable called $middle_links. I’ve taken the extra step to add in a styling class for an active link versus a non-active link.

for ($i=1;$i<$loop;$i++)
{
	$page_start_at = ($page_link * $limit_num) - $limit_num;
	if ($curr_page==$page_link){;$link_class='page_btn_active';}else{$link_class='page_btn';}
	$middle_links .= '<a href="'.$back_forward_url.'&start_at='.$page_start_at.'" class="'.$link_class.'">'.$page_link.'</a> | ';
	$page_link++;
}

Finally, we’ll put everything together and print it out. We have to do one last check before our print which is taking off the extra ” | ” from our loop if there is no Next button. You can also see that we’ve added a div to style the entire link bar.

if ($next_link==''){
	$middle_links = substr($middle_links,0,-3); // take out the extra " | " if we have no Next button
}
 
print '<div id="page_link_bar">'.$previous_link.' '.$middle_links.' '.$next_link.'</div>'; // put everything together

There you have it!

Some hints to help you along as well:

• If the start_at value is not set in the URL, you need to set that to 0
• Always do verification on your REQUEST (GET & POST) variables. is_numeric() function works well for the start_at variable.
• To make it work, you’ll just append your variables into your MySQL statement using LIMIT.

  SELECT * WHERE id=1 ORDER BY id DESC LIMIT $start_at,$limit_num

1. Title
2. Date
3. Story (HTML)

The administrator will need to be able to add news items, edit existing items and delete items as well.

As imagined, this requires 3 separate form functions:

1. Add Function (title,date,story)
2. Edit Function (title,date,story)
3. Delete Function (id)

To make this form more efficient and easier for the user, a good coding practice is to join parts of these functions. What we end up with is only two user form pages and integrated functions. The initial page will consist of two separate forms:

1. Add Form with Title Input Box
2. Edit/Delete Form with Select ID Box

The Add form submits to a database insert query and then returns the edit function with the inserted mysql row id. This cuts out the code for making an entire add form and insert code. The Select Box actually only submits to the Edit Button, which the function is self explanatory. Finally, the delete button uses a simple onClick method to append the selected ID onto the URL, by which the page recognizes the GET variable and deletes it. Of course, it’s good practice to always have a confirm delete function, before passing the URL on.

Tricks like these are easy to implement with simple forms, but efficient coding practices are hard to maintain with larger and more dynamic forms. These types of forms take much more time to ensure the correct usability and efficiency are implemented. Take for example a recent form I did for listing an item on an eBay like site. I’ve done plenty of real estate listing forms before, but this one would be used by the general public, not just an administrator. It’s easy to teach an administrator what to do and what not to do, but when coding for the general public, all possibilities must be considered!

A good initial step is to write/think about the usability aspect of the form – that will save you some time! One of the main issues (small, but still an issue) was denying multiple listing adds from a user. Let’s say a user wants to create a new listing. With multiple steps (like on eBay), we can’t just have one big add form, we need to break it up. If we break it up, generally, the first part of the form will add a new row to the database and the remaining parts will update that row. Simple right? Wrong!

The problem here is the ability for users to go back and refresh, which means multiple rows added, which equals a dirty database and a bad user experience. How can we fix that? Well one of the first thoughts was to add a random ID on the initial load of the first part of the form, before anything is added. That ID is added to the database with the first data, and if the back button is pressed, we can check to see if that ID is present. Unfortunately, that solution doesn’t solve the problem entirely. If the user goes back (too far) to the homepage and returns to the initial part of the form, the random ID is different and so it starts a new row in the database. To really solve this problem, we need to thoroughly understand what is happening here.

Users like to go back and forth between pages, which can sometimes drive a programmer nuts! Users do this to check over or edit the data they’ve put in, fair enough. What we need is a system that allows them to jump to any page, see data they’ve put in before, and edit that data. This can get a little tricky when you start including server side error checking, messaging, and splitting the data between the POST data (what they’ve submitted) and what’s already in the database, but we won’t touch on any of that. What we’re interested in here is allowing the user to jump between pages with their data in there. The answer then is to be filling in forms with information that’s already in the database. Where then do we add the database row for which they’ll be using? The answer would be before the form starts! The problem with that though is, again, multiple row adding.

Say the user goes to the add a new listing form, and a row is input into our database with an id returned. Everything is good, the user can jump to any page to update info, except our initial page, because it will add another row. To prevent this from happening, we use an active field in our row, as well as putting the users’ username in there. The active field is defaulted to zero (0) and only is active when the listing is complete (or when the user is done jumping around). When the form starts now, we can then use a session variable to access to the user’s username and lookup to see if there is a listing by that user with active set to zero. If there is (means they’ve refreshed/revisited that page), we’ll use that listing id, and if there isn’t (they just started the form up) we’ll create a new row with the username in it and use that listing id. Everything else falls together, and now a form process with step by step links is available to the user to jump around wherever they want without losing any data.

To implement restrictive step links at the top (they can only click on where they’ve been), you can store what step that listing is on and update it in each subsequent function. Since the user is able to jump around though, you’ll want to make sure that the step only gets updated if the new value is greater that the current database value.

Overall, efficient code and good usability takes great planning.