How to create 323 unique landing pages with Pretty URLs – from just one page

Last updated November 19th, 2013 at 05:14 pm

The Challenge

nSiteful Client Jay Maurice operates a music instruction business called Lessons In Your Home. At this writing, the business has over 200 active music teachers in eight major U.S. markets. Jay wanted to optimize his email marketing and pay-per-click advertising campaigns by having a customized landing page for each market and each instrument taught (35 as of this writing) — and each combination thereof.

In other words, he needed 323 uniquely relevant landing pages with Pretty URLs. What’s more, he needed a solution that would accommodate new landing pages when his business expanded to new markets and started offering instruction in new instruments. (The solution also needed to remove landing pages for markets that are closed and instruments for which the business no longer offers instruction.)

Let’s get specific

To be relevant (for humans) and unique (for search engines), each landing page needs to display information about the market (when applicable) and instrument (when applicable). More specifically, each page should include:

• text references to the city market, for market-specific landing pages;
• text references to the instrument, for instrument-specific landing pages;
• images of the instrument, for instrument-specific landing pages;
• images of the Director of the market, for market-only landing pages; and
• below-image captions referencing the name of the Director of the market, for market-specific pages

(Keep reading for enlargeable screen shots of the final product.)

Clearly, I wasn’t about to create 323 physical Web pages. This had to be done programatically. But before I delve into the approach, let’s talk about “Pretty URLs” for a moment.

What are Pretty URLs?

Pretty URLs (also known as search-friendly URLs and user-friendly URLs) are Web-site addresses that consist of words and phrases that are meaningful to humans. Ugly URLs, on the other hand, typically include cryptic query strings — question marks, ampersands, equals signs, and esoteric numbers that bear no relation to the content of their pages.

Ugly URLs are almost always associated with dynamically generated pages — pages that typically involve programming scripts and backend databases.

The best way to explain the difference between Pretty and Ugly URLs is with examples.

General Examples of Ugly vs. Pretty URLs

Example of Ugly URL for a page that displays gold (subcategory, or “subcat”) earings (main category, or “cat)”:
http://mysite.com/index.php?cat=213&subcat=4
Pretty URL version of the above:
http://mysite.com/earings/gold/

Examples of Pretty URLs needed for Jay’s landing pages

So, in the case of Jay’s requirements, he wanted landing pages whose URLs look like these:

Landing page for Atlanta Piano lessons:
http://lessonsinyourhome.net/lessons/atlanta/piano/

Click to enlarge:

Landing page for Piano lessons, irrespective of market:
http://lessonsinyourhome.net/lessons/all/piano/

Click to enlarge:

Landing page for Atlanta lessons, irrespective of instrument:
http://lessonsinyourhome.net/lessons/atlanta/all/

Click to enlarge:

Where most Pretty URL tutorials fall short

Most “Pretty URL” tutorials I’ve encountered on the Web focus narrowly on one — or, at best, just a few — of the many puzzle pieces required to convert Ugly URLs to Pretty URLs. The problem with such tutorials is that they’re like explaining how to parallel park by describing only how to use your directional signal.

The fact of the matter is that most Pretty URL solutions involve several related mini-technologies:

1. a structured data source (usually a database; MySQL, in my case) from which pertinent content is pulled
2. a scripting language for interacting with the data source (php, in my case)
3. a series of scripting components that manages the process of converting the elements of the Ugly URLs to a Pretty URL — in my case:
   • Apache Web server
   • Apache’s mod_rewrite module of the Rewrite Engine
   • the .htaccess file
   • regular expressions

This tutorial is more of a case study than tutorial. It attempts to demonstrate how the various puzzle pieces fit together conceptually.

Step 1: Laying the groundwork

The good news is that we already had nearly all of the building blocks in place!

nSiteful has been working with Jay and Lessons In Your Home since September of 2010. Together we redesigned his original Web site. Insofar as a critical element of Jay’s public-facing site was to be a listing of instructors along with the cities they serve and the instruments they teach, we implemented a database-driven approach from the start (complete with turnkey CMS modules). We built database tables for Markets (“cities” table), Instruments (“subjects” table), and Instructors (“instructors” table) from the get-go.

(The database was substantially extended in 2011 when we undertook a major enhancement project to create a backoffice Intranet application. But I get ahead of myself…)

The only data pieces that were missing were images for the markets and instruments. Keep reading to find out how we solved that.

Step 2: Implementation

Conceptually, here’s what we came up with.

1. We would create a single physical PHP page (index.php) in a new directory called /lessons/.
2. Based on the city and subject GET variables in the query string, custom php functions would pull appropriate data. Other custom php functions would “sanitize” and “prettify” the names of cities and instruments, for use in the Pretty URLs. For example “Miami/South Florida” would be converted to “miami-south-florida“; “Washington, DC” would be converted to “washington-dc“.
3. Using conditional php statements, relevant text would appear in all the right places ̵ just like “mail-merge”, as Jay put it.
4. To “prettify” the URLs, I’d add the relevant regular expressions code in the .htaccess file of the /lessons/ directory.

What about the images?

Finally, to incorprate appropriate images, we came up with a simple solution that (a) minimized the need for me, the developer, to intervene and (b) precluded the need for a new CMS which would take time and cost (Jay) money.

Namely, I created two new directories on the Web server, one of which is dedicated to storing and serving city images and the other of which is dedicated to storing and serving instrument images.

Jay already knew how to use his hosting control panel’s File Manager interface to upload images. So, all Jay has to do is this:

1. name images appropriately — so that each file name exactly matches the sanitized/prettified name of its corresonding entity
   Example: The portrait of the Washington, DC director would be either washington-dc.jpg, washington-dc.png, or washington-dc.gif
2. upload each image to its proper directory
3. upload a “default” image in each directory in the event no corresponding image has been uploaded yet

Using another set of custom php functions, the page “knows” whether to display a corresponding image or the default image for any given landing page.

In addition, using custom functions I created years ago — which utilize the GD Library, incorporated into most PHP installations — Jay didn’t even have to resize images before uploading. These functions do the resizing for him.

PS: Links to other Landing Pages

We also decided to inlude in each landing page pertinent lists of links to other landing pages. This way, someone who landed on the Atlanta Piano Lessons page would learn that other instruments (for other children, perhaps) are also taught by the company in Atlanta. (And if search engines learn the same thing, that’s fine with us.)

Again, using some conditional php, we were able to include the pertinent listings.

Conclusion

I understand this wasn’t a tutorial in the usual sense of the term. There were no code samples. No screencasts of me typing php code into Notepad ++. Not even a code snippet of the mod_rewrite stuff from my .htaccess file.

Ok… here’s that code snippet:

RewriteEngine on
RewriteRule ^(.*)/(.*)$ index.php?city=$1&subject=$2 [NC,L]

My goal in this article was to describe the solution conceptually, in the context of all the pieces involved. In a future article — especially if anyone expresses interest — I may provide more granual tutorials on the pieces of the solution.

Thanks for listening. Please feel free to post your comments and questions below.