GuitarGav

Update.
I can now get into my backend and pages have returned, by removing jetpack from the plugins folder.
I tried installing the 2.5 plugin via the zip file to see if that would work, but no, that hosed WP again.

Same here.
Upgrade has hosed wordpress.
Renaming the plugin folder has restored the front end – though it may be just the caching plugin serving the static html as not all pages are appearing.
Rolling back to 2.4.2 hasn’t helped though and I still cannot log into the back end. wp-admin is unresponsive.
Turned on WP debug, but nothing in there to indicate what the issue is.

@klark0 and @yoast.

Thanks for the code snippet. Will implement it now.

I have 10 CDN subdomains (i.e. media1.domain.com through to media10.domain.com) so there will still be a mismatch between what the site map reports and the subdomain the <img> tag refers to on the page. We shall see how it goes with Google (and I can always dial down the number of sub-domains).

@alexander
Not wanting to turn this into a CDN debate, but I did look at CloudFare. It looked too good to be true. However, didn’t like this in their terms where CloudFare reserves the write to update your content to “Add tracking codes or affiliate codes to links that do not previously have tracking or affiliate codes”.

Thanks for all the help.

Thanks. I will give that a try and see if SERPS bounce back.

I have the same issue, but with using CloudFront CDN (with a CNAME subdomain).

A week or so ago I saw google de-indexing my site’s images in webmaster tools. Many of these images were named for better seo. At the same time the images were de-indexed I saw a big drop in traffic and rankings.

Of course, this may be a coincidence, but the site map for pages points to the origin image location, which is still valid, however when google indexes the web page all the images are pointing to a different URL (the sub domain for the CDN). I am wondering if there has been another google update and this mismatch has raised a flag in google that’s given me a SERP penalty…. Which of course would be ironic if this is the case, given that this is an excellent SEO plugin.

I thought of using Yoast’s API to set all image locations to one of my distribution servers, but that would still cause a delta between the sitemap and page image locations as Total Cache spreads the image path across a number of distribution server CNAMES. There doesn’t appear to be an API in W3C Total Cache to get the image path it used and then inform Yoast’s SEO plug-in.

Anyone else noticed an impact recently in their SERPS when there is a difference reported in the sitemap to what is actually on the webpage?