Welcome to the Q&A Forum

A 503 error is a service unavailable error.  I have seen situations where redirects are incorrect and loop.  Depending on the hosting setup, this can trigger various HTTP error codes.

The best way to debug this is by looking at your Apache access logs.  Scan your logs for the 503 errors. Pay attention to the URL being requested as well as the referring URL.

Very likely, there's some looping process and in cases when Apache runs on FastCGI, you can get a 503 error due to too many processes being triggered.

Also, due to how WP handles 404's, I've seen many plugins mask underlying causes. So if you have any plugins that impact error handling, you may need to remove those while debugging.

You can also use http://www.redbot.org/ to check the headers for any page that should be redirected. That tool should return a Location header with a URL.  Visit that Location URL in your browser and make sure it resolves.

The goal here is to try to replicate the behavior. Once you can replicate the behavior, dig into your redirect/rewrite rules and examine the logic to determine why you are seeing the loops or failures.

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.

If you use gLTDs as your sub-directories, you can then use WMT to set preferences.

See a further discussion here:

https://support.google.com/webmasters/answer/182192?hl=en#2

From my understanding (as a hosting provider not a SEO), is that increasingly signals coming from on-page or WMT are far more important that server location, IP or other hosting related information.  This makes sense with more and more CDNs.

You may also want to see:

http://googlewebmastercentral.blogspot.com/2013/04/x-default-hreflang-for-international-pages.html

In terms of what to optimize that is up to you, but the important part is to give Google clues as to what pages you want ranked where/how.

You likely have a .htaccess issue causing a rewrite error.   You may want to examine or replace your .htaccess with a default.   Also, I've seen some plugins cause this error.

What is happening is this:

http://www.atozqualityfencing.com/newsite

is sent to:

http://www.atozqualityfencing.com/newsite/

Note the trailing slash.

But that page is returning a 404 error.

If I go to

http://www.atozqualityfencing.com/newsite/index.php it redirects to

http://www.atozqualityfencing.com/newsite/

So there is likely something wrong in the redirect rules.   I would try disabling all plugins. If that fails, compare the current htaccess to a default one and remove any modifications.

.