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

Share this!

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)”:
Pretty URL version of the above:

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:

Click to enlarge:

Landing Page for Atlanta Piano Lessons

Landing Page for Atlanta Piano Lessons

Landing page for Piano lessons, irrespective of market:

Click to enlarge:

Piano Lessons, Any Market

Piano Lessons, Any Market

Landing page for Atlanta lessons, irrespective of instrument:

Click to enlarge:

Atlanta Lessons, Any Instrument

Atlanta Lessons, Any Instrument

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.

Lists of Links to other Landing Pages

Lists of Links to other Landing Pages


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.

Share this!


The nSiteful Tech Blog (the official blog of nSiteful Web Builders, Inc. since January of 2013) is where I (Jeff Cohan) and (occasionally) associates will be posting articles of potential interest to like-minded techies, nSiteful clients who are playing active roles in the maintenance of their own Web sites and blogs, and pretty much anyone interested in how Web strategies and tools can help them reach their goals.

This entry was posted in Case Studies and tagged , , , , by Jeff Cohan. Bookmark the permalink.

About Jeff Cohan

Jeff and his wife, Margie, are the proud parents of Sarah and Jake. Jeff is the founder, president and chief cook and bottle washer of nSiteful Web Builders, Inc., a Web development and Internet Consulting firm. In his spare time, Jeff builds Web sites and Web applications, plays guitar, putters around in his basement woodworking shop, mercilessly spoils his grandchildren, and creates videos from more than two decades of home movies. His current video project is an extended montage of people (mainly family members) asking him to stop filming them.

4 thoughts on “How to create 323 unique landing pages with Pretty URLs – from just one page

  1. As the client that wanted the landing pages I can say I’m happy. We are just putting these “pretty url’s” to use so I hope to check in soon and tell you how well they are working.

  2. Jeff – this is brilliant! The concept makes perfect sense. Is this something that you would create a WordPress plugin for, or is it still better to create it the way that you have? Another question: for a permanent page feature in WordPress, is it better to use a plugin or to strip the code from a plugin and drop it directly into the page? I am thinking about page loading speed – especially with mobile capabilities.



    • Hey, Rick –

      You asked:

      Is this something that you would create a WordPress plugin for

      It’s certainly a good idea to develop such a plugin for dynamically creating landing page, and one or more good ones may already be out there. Since the Lessons In Your Home Web site isn’t based on WordPress, developing the functionality as a plugin wasn’t a consideration for that project.


      Another question: for a permanent page feature in WordPress, is it better to use a plugin or to strip the code from a plugin and drop it directly into the page? I am thinking about page loading speed – especially with mobile capabilities.

      Excellent question. I’ve been working on an article whose working title is When a plugin isn’t the answer. I just finished a project in collaboration with another WordPress developer that’s a case in point. She did the main Web site in WordPress; I created an application in PHP and MySQL that we “plugged into” the Web site, but natively, not as a plugin.

      For your specific case, here comes a classic techie answer: It depends — on the functionality and the plugin. Hey, we’re long overdue for a chat anyway, so ring me up some time and we can discuss!

Leave a Reply

Your email address will not be published. Required fields are marked *