Indexing AJAX content

Search Engines

One of the more compelling reasons to stay server-side and avoid putting all business logic on the client is the matter of search engines.   Google and the other search engines have not traditionally indexed dynamic content, as they don't run the client side JavaScript necessary to realize the dynamic content.

We now support the search engine indexing of AJAX pages, so this reason is now not so compelling.

Ajax Indexing

A year or so ago, Google introduced the Ajax crawling specification, which described a cooperative method where the site can enable indexing of dynamic content by Google.  Basically, Google interprets hash-bang '#!' hash fragments, where it finds them while scanning html, as a request for special treatment; the special treatment is to rephrase the URL replacing the fragment with a specially named GET parameter carrying the fragment value.  The site can then generate, server-side, a version of the page containing the content, for Google to index.  In Google's search listings, the fragment is again a hash fragment.

Rdbhost now provides the server-side component of the Ajax indexing process, for any site hosted on Rdbhost.  Use the '#!' prefix for your internal links, Google will request them with the special '_escaped_fragment_' parameter, and Rdbhost will use a server-side 'headless' browser to generate a content-full version of your page for Google.

Ease of Implementation

Rdbhost intends to make easy web-sites as easy as possible; now we make Ajax-content index able with no effort to you.  The only requirement of you is that you use the '#!' notation for your internal links.

See for Yourself

You can verify this yourself, by entering such a URL in the browser.  If the link is 'http://demos.noservercoding.com/hashtest.html#showmore', the special request URL would be 'http://demos.noservercoding.com/hashtest.html?_escaped_fragment_=showmore', and requesting that URL with your browser will provide a pre-rendered page.  Use 'show source' with each version of the URL will show the difference.

Links:
  Ajax Client-Side Version
  Server-Side Version

Easier Hosting

There are a couple of new features to tell you about this week;  One will be discussed here today, and the other will be in another post in a couple of days.

Rdbhost has always been flexible about where you can host your website's static files:  You can host them on any static server, including free servers, on Localhost for development, and even on GitHub or Assembla for git-commit ease of deployment.  Your SQL database account can be accessed using the JavaScript/jQuery module, from any host.

Static Hosting

You can also host your static content here at Rdbhost.  While we do not make file space available to our customers (we are a Database hosting service!), we do provide a facility to put file contents into database blobs, and those blobs can be retrieved using natural short URLs.  Your static content can be hosted in static 'pseudo-file's, and the dynamic content in SQL database tables.

SFTP Server

The new feature makes these pseudo files easier to manage.  We now support an SFTP server, for managing your static content.   This server is on port 24 at www.rdbhost.com, and functions like any other SFTP server, except that the files you manipulate are actually just blobs in the pseudofiles table.  The server also uses 'magic' to determine the correct mime-type for the content you store; when you retrieve the blobs from a browser or other web client, the stored mime-type is sent as the Content-Type header.


The SFTP server uses account and password logins only; the login is your Super role-name (such as 's0000000907'), and the corresponding authcode.  These are available on your Roles page.  To create the 'lookup.pseudofiles' table to start, enter a domain alias from the profile page;  You should have a domain registered for the new site.  Setting the domain alias tells Rdbhost.com that you intend to serve static content under that domain.

Quirks

In minor ways, this SFTP server is different than others you have use.

The server will maintain empty directories during an SFTP session, but they are forgotten at the end of the session.  Similarly, file attributes can be changed, but the changes are forgotten at the end of the session; the 'files' are always readable to the public, and writable by the Super account only (unless you have granted specific privileges otherwise).

Testing

The SFTP client has been tested with the following clients:
   WinSCP 5.1.2
   Expandrive 2.4.0
   CoreFTP LE 2.2
   BitKinex 3.2.3


The RdbAdmin utility is an alternative way to enter data into the psuedofiles table.

See User Domains
       RdbAdmin Video
       SFTP Server