Using a third party server to host site elements

[zealmedia]

Hi guys -

I have a client who are recently experiencing a great deal of more traffic to their site. As a result, their web development agency have given them a server upgrade to cope with the new demand.

One thing they have also done is put all website scripts, CSS files, images, downloadable content (such as PDFs) - onto a 3rd party server (Amazon S3). Apparently this was done so that my clients server just handles the page requests now - and all other elements are then grabbed from the Amazon s3 server. So basically, this means any HTML content and web pages are still hosted through my clients domain - but all other content is accessible through an Amazon s3 server URL.

I'm wondering what SEO implications this will have for my clients domain? While all pages and HTML content is still accessible thorugh their domain name, each page is of course now making many server calls to the Amazon s3 server through external URLs (s3.amazonaws.com).

I imagine this will mean any elements sitting on the Amazon S3 server can no longer contribute value to the clients SEO profile - because that actual content is not physically part of their domain anymore. However what I am more concerned about is whether all of these external server calls are going to have a negative effect on the web pages value overall. Should I be advising my client to ensure all site elements are hosted on their own server, and therefore all elements are accessible through their domain?

Hope this makes sense (I'm not the best at explaining things!)

[oneticsoft]

I don't recomend to have the resources and database to other server than files, it makes some flood traffic between servers, the resources are harder to load and the site optimum speed is decreased. Also you can't compress this content so they are downloaded independently.

[Highland]

Couple of notes for you

1. There isn't any SEO impact on WHERE the data is loaded from. Look at any major website (especially one that ranks well) and they're openly using content delivery (like Akamai, Amazon S3/Cloudfront, etc) for static content. This is good business practice because it takes that load off your web server and often places the content closer to where the client is. Faster content delivery can help SEO if you have a slow server.
2. If they're using the raw S3 buckets I would HIGHLY suggest signing up for Cloudfront. There's two benefits to doing this. First, you put the content into Amazon's cloud, where it is more readily available. Second, you can use domain aliasing to help obscure the source. For instance, let's say you have an images bucket. You could add a CNAME DNS record for images.yourdomain.com and then put that into your source code. You can still see where the DNS takes you, but it's not obvious to the general public. The cost difference between raw S3 delivery and Cloudfront is negligible.

Oh, and I use Amazon Cloudfront for my delivery. Never had any SEO issues with doing so.

[Dan-Petrovic]

Hosting images externally never had any impact on cases I had a chance to observe. The only problem I can think of is that you lose control over loading times or if somebody takes an image and links (credits) the image hosting domain instead of your domain.

[jeff-rackaid.com]

I work with a number of high traffic sites (TB's of data each day, 10's millions page views/month).  With many of these sites, we have offloaded static content to either dedicated static content servers (typically cloud based so we can scale up and down) or to content deliver networks.  I've not had anyone report any SEO impact.

In contrast, they often see user engagement (page views/user), repeat visitors, and other traffic metrics improve.  Users like fast sites.  Also, Google apparently likes fast sites too, so while I've not seen it, you could actually get a boost in your SERPs due to faster loading pages.

If you break down a modern web page, you will find numerous elements required. Dozens of images, CSS, javascript as well as the page itself.  All of these items require a request to the web server.

With some graphic intensive sites, I've seen as much as 95% of all web server requests (HTTP requests) be attributable to static content.  By moving these HTTP requests to other systems, you free your primary server to handle the application.  This provides a better user experience and improves scalability.

Content Delivery Networks

I do not use Amazon's Web Services so I do not know specifically what they offer.  But here are two CDN's Ihave used with good success:

Internap:

http://www.internap.com/cdn-services-content-delivery-network/

Edgecast:

http://www.edgecast.com/

One method I look for is called "origin pull." With this method, you do not have to upload files to the CDN. The CDN will fetch them automatically from your site as needed.  I found this is much easier to manage on sites that have frequent content updates.

[zealmedia]

Great advice, cheers Jeffery!

[loopyal]

Hello Zeal Digital,

I use a CDN (Content Delivery Network) for images, CSS and javascript.

Doing that adds only about $10 to cost per month for a site that had around 800,000 pageviews per month.

You have complete control over the images. If there is a problem, you can force the CDN to flush a file and reload it from the source. You add code to your .htaccess file that tells the CDN how long to store images before fluching them and getting a new copy. It is all automated, there is generally no work for you to do. I host with softlayer.com and this is part of their service.

The change from self-sourced images, css and scripts had a massive improvement on the server.

• it is a 16-processor linux box with twin 15,000rpm SCSI drives and 12Gb RAM - it is quite fast!

Page delivery times improved by 1-2 seconds.

The server now is so lightly loaded that it could be downgraded to save more money.

It has zero effect on SEO. The CDN is accessed using a CNAME.

-   static.domain.com  - so don't worry about it looking like components are from other places.

The CDN has servers all over the world, so no matter where the visitors are, it is only a few hops for them to get most of the content, making it much faster for someone in Australia who would normally pull images from a server in the USA.

Your only problem with Amazon S3 is that they have crashed it a few times, but other than that, it is a good thing to do.

I wouldn't advise them to self-host, unless you want to increase their costs, server loading and page delivery times.