Creating Pages to Rank Dynamic Content for Good SEO Results
Recently I was privileged to attend a Google Webmaster Hangout in person. It was a very enlightening experience.
There was a great question, scenario posed by one of the online attendees concerning a JavaScript rendered page.
Unlike the common scenario where a fast food JavaScript framework is used to rendered all content in the browser his scenario was more legitimate. It was a travel booking site
The site's primary feature is showing current hotel rates for a location and date.
As you know search engine spiders don't make much effort to render content using JavaScript, at least in the first pass. They get around to it as they have capacity.
This is why it is important to have search consumable content rendered and ready to go on demand.
The scenario is a great case study for both web development and search engine optimization!
From an SEO perspective how can a site that leans heavily on real-time data attempt to rank for keywords?
For developers how can you develop a site that offers dynamic data like current hotel rates where the data supplied is rather slow?
I have answers for both concerns that should help sites like this one improve their overall user experience and ability to rank for their target keywords.
How a Dynamic-Client Rendered Page Works
Sites like this travel site lean on data supplied by a fluctuating data source. They cannot reasonably cache the data because it changes too often.
If this were a site listing movie times at local theaters it could cache the data for a day or more because the data is relatively static.
Each time a hotel books a room the availability and even the price may change. It could affect not only that hotel, but others in the area. So the data is rather unstable.
A specific page's life span is also limited. Would anyone want to reach a page for last week hotel rates?
To avoid the perception of a terrible delay websites migrated from a 100% server rendered web page to pages leveraging an app shell and JavaScript to make asynchronous network calls to APIs for data.
Now they can display something so the user does not 'feel' the delay so much.
Once the data is fetched it is then merged with a markup template in the browser and then added to the page (DOM if you want to be completely technical).
Travel data is notoriously slow, so the pages for this site take a long time to render. If you have ever used an online travel site, and I bet you have, you know what I mean.
The app shell approach allows the site to provide an experience that hopefully reduces customer anxiety.
Unfortunately, for good reason, Google and other search engines are not as patient as most consumers for this sort of content.
This means the search spider only sees the app shell content and not the real-time hotel data.
To the search engine the 10,000 locations you want to rank for now look like the same page 10,000 times.
Do you smell duplicate content? I do.
A question I asked myself as I listened to the hangout attendee is why would Google index data that would certainly be stale by the time it was evaluated?
It wonโt. It would be not be a good experience for both Google and the site to offer.
Think about it. When a consumer searches for 'Cheap New York City Hotel' and they see you have a $75/night rate in the search result, but when they visit the page it is $125 they are not happy.
They may blame Google, you or both.
And don't forget how long that data may be valid, until midnight the day of booking.
How can the travel site give Google and customers something they could consume and index?
The answer is right there in the current results ๐
Provide Consistent, Indexable Content for Google
When a page depends on real-time data that changes like hotel room rates and availability it is impossible for you to attempt to rank.
The problem is you want a search engine spider to:
- Wait till your data renders
- Once it does the data has a short life cycle
Neither scenario is good for you. There has to be a better way.
I think there are two ways you can work on creating content that may help a site rank in these scenarios.
Render Rank Worthy Content Ahead of Dynamic Content
Instead of the page being 100% about the dynamic data, find information that provides value around the run-time data.
In the case of local hotel rooms, they could attempt to create real localized content about the area. For example, parks, local attractions, transportation and types of hotels. Even a list of possible hotels.
Don't just copy Wikipedia for this information, you will need to do the legwork, sorry.
They might even consider highlighting user generated content and reviews about the area and hotels.
As part of this layout you can include your hotel search form, pre-filled with the location information. All the customer will need to do is supply a check in and checkout date.
After this unique content you can provide an area to render the current hotel availability and rates.
I can think of several user interface approaches for this sort of thing. You will want the user to know when the hotel rates they requested are available, so make sure there is something that will alert them to the rendered data.
Just don't disrupt their engagement with a giant full screen pop-over! Everyone hates those things.
I think this approach is good because you are offering value to the customer and content Google can index.
As I listened to the scenario being described I reflected at my own experiences with hotel and flight booking sites over the years. Many times I wanted to know more about the area while I deciding where to book a room or flight.
In the case of flights, airport layovers are important for me. How often are different locations affected by weather? What is the dining and restroom situation? Can I plug my laptop in and get free WIFI?
For hotels, what sort of dining is close by. Are the neighborhoods sketchy?
Do you see where I am going?
SEO Targeted Landing Pages
If you don't want to reserve some pixels at the top of a data page like these then consider making dedicated pages for different locations with the type of information I outlined above.
You should still feature the rate search form at the top of the page. It is the main call to action after all.
I am borrowing this concept from e-commerce strategies I have been studying. Because the hotel booking data is real-time it is not indexable, so don't worry about that page ranking.
Instead create a dedicated page for a specific location. You could even create specific pages for actual hotels. In this case you might even be able to get their staff to help populate the content.
Hey that sounds awesome, let someone else do the work for you.
As I began research for this article, I noticed these are the type of pages ranking for local hotel room search phrases.
Good SEO professionals know copying the type of content currently ranking because search engines have collected data on what content type matches search intent.
In the case of local hotel rates you can see pages offering the 'Top' hotels are doing well. The landing pages feature the rate search form at the top and then a list of possible hotels. No rate information.
The key here is the site has the general hotel information, it is static. The booking site can create static landing pages based on this information.
It meets all my technical criteria as well as Googles. This makes it a proven, repeatable strategy for a travel site to rank in Google.
Now you have a truly static page that should have quality, useful information travelers would like. Because the content is static, and good quality (right!), Google should love it.
The content should also be good enough it can attract links, which will also help you rank.
The organic problem here is the business owners want to lean too heavily on content and data they do not need to manually create. Unfortunately, that is not what customers are interested in finding.
This is a big reason why most travel sites rely heavily on paid search for traffic. I bet if they invested a portion of that budget on real, quality content they could earn as much if not more free traffic.
Solving Technical Problems
Because these pages are populated with real-time, dynamic data they use asynchronous fetch (AJAX for your old schoolers) calls to an API.
Travel services, like Sabre, are notoriously slow and you don't have any control over their latencies. You just have to deal with it.
You could attempt to continuously query the API for updated data and pre-render your pages, but this can create all sorts of problems. Plus, it may violate your terms of service etc.
Not to mention you will run up your server costs and overhead.
The other catch here is often these APIs require you to connect using secret keys. This means you cannot connect directly to these services from the browser.
There are many legal, technical and security reasons why this is the case. I won't get into them, just assume you must connect to the API from your server.
This creates an extra layer of latency. The browser must make the API call to your server, which then relays the request to the third-party service to get the data.
I will be generic and say the hotel booking API call takes 30 seconds to resolve.
This is a long time in terms of how patient real people and Googlebot are.
Googlebot just moves on after a period of time, let's say 10 seconds (FWIW it varies). Now Google just sees the app shell, and not the room rate data.
Actual customers will wait a little longer, at least for travel sites because we have come to expect these delays.
Above I described two scenarios, one where you have a page with static content and a search form that loads a search result page. The other is where you have content and add search results.
I like the latter as a more realistic solution, so I will use that in this example.
Most sites at least attempt to provide some sort of interactive animation when a search is submitted to keep the customer engaged. Smart sites will display messages to help inform visitors about the service and other travel tidbits.
So how can you create an experience that is engaging without sacrificing customer conversion?
Ultimately, I think the search content can replace the static content supplied when the page initially rendered. This means you will also add filtering and sorting functionality.
You can render the data manipulation interface either when the search is submitted or when the data is available.
There are all sorts of layout possibilities I can think of you can offer to allow them to sort and filter the results. I will assume you are using some sort of left-hand column faceted filter and a list header for sorting since that is the most common travel layout.
If you render these fixtures when the search is initiated, you should do so in some sort of 'disabled' state.
My first approach would be to overlay these elements with some sort of opaque layer so they are visible but 'blurred' out. Personally, I like the acrylic look, but you can go with a foggy overlay or whatever floats your boat.
return admin.api.get( { mode: "cors", url: "API-URL" } ) .then( function ( response ) { if ( response.ok ) { return response.json() .then( function ( data ) { contenterEle.innerHTML = Mustache.render( template, data ); } ); } } );
When the data returns and you render the content and suppress the overlay. This is where having a basic knowledge of CSS transitions can be your friend.
Rendering the hotel data is pretty simple. Once the fetch call resolves you can then merge the data with an HTML template, I like Mustache.
The rendered HTML can then be added to the page by selecting a wrapping element and setting the innerHTML property.
You can make it just 'pop' into the page, but an easing transition might be a nice touch.
Another, advanced technique I would be tempted to pull off is leveraging the static hotel items on the page to add room rates as they are available.
Just a thought, but nail the initial suggestions first ๐
Wrapping It Up
This was a great scenario to be brought up in the Webmaster Hangout. It touched on two areas I love, web development and SEO. It also raised the important question of how search engines handle JavaScript and dynamically rendered content.
As you can see a good solution is to provide good value to both the customer and search spider. Without good, reliable content neither have context to 'trust' the page.
In this scenario customers realize the hotel room data is going to be a bit delay, but Googlebot does not have the same patience.
By giving Google what it needs you can improve your ability to earn free search traffic as well as raising the bar in your industry.
The dynamic data also gives you a nice opportunity to flex your web design chops and create a pleasant user experience. Use the dynamic content to enhance, not frustrate the connection to your brand and service.
Get these elements right and I think you will reap the rewards.