I'm writing a deployment script that works like this:

  1. Copy the current document root site.current in a new folder at the same level.

    • /web/site.current copied to /web/site.new
  2. Update the new folder. Meanwhile, visitors still see the current site.

  3. When it's ready, switch folders :
    • /web/site.current moved to /web/site.r42
    • /web/site.new moved to /web/site.current.

The only problem is that there is no way to make this switch atomic. It's therefore, in theory, possible that someone (visitor or web crawler) tries to access the website during the few milliseconds where the document root site.current doesn't exist.

  • Given that I have roughly 1000 unique visitors per day, should I consider highly unlikely that anyone ever happens to visit at this precise moment, and stop worrying about it?
  • Apache seems to raise a 500 error when the document root doesn't exist. I figured it's better than a 404 for web crawlers, hence not penalizing SEO. Am I right?

Note: I have already spent countless hours trying different methods (from RewriteRules to ErrorDocuments to MultiViews) to display a maintenance page to the user if the document root isn't there, so this isn't the point of my question. I'll be glad to hear a new solution as a comment, but now I highly doubt there is (especially given that I can't edit my vhost config, only .htaccess files).

Note 2: I'm not using a symlink switch (that would be atomic) because Apache uses some sort of cache on symlinks, and I can't install mod_realdoc to fix the issue.

  • Were you only trying RewriteRules "to display a maintenance page"? Or did you try using mod_rewrite as part of a solution to your main task? It's just that you could potentially rewrite the request to the appropriate subdirectory using mod_rewrite - essentially an "instantaneous" switch - without having to "move" anything. Although the filesystem path that the site works out of will now be different, if that matters?
    – MrWhite
    Jan 25, 2017 at 15:14
  • I was trying rewrites to display the maintenance page. I understand your point, but I'm not sure it's possible to use rewrites the way you suggested. The .htaccess used when accessing the website is inside the folder that is moved, so I have to use the .htaccess in the parent directory, i.e. outside the DocumentRoot, and at this point I can't access other files outside the DocumentRoot.
    – sylbru
    Jan 25, 2017 at 17:55
  • I could set my DocumentRoot on /web and have my .htaccess rewrite all requests to /web/site.current or /web/site.r754, but then PHP $_SERVER variables like SCRIPT_FILENAME contain the subfolder (site.current or site.r754) in the path, and I don't want that. (I read it wouldn't do that with mod_php but here the server uses FastCGI)
    – sylbru
    Jan 25, 2017 at 17:59

1 Answer 1


There is no SEO Risk from temporary errors on your site. Google is very forgiving of small amounts of down time. Down time lasting less than a day will generally not hurt your site from an SEO perspective. When Googlebot encounters a 404 or 500 error on a page that it has found in the past, it tries again for 24 hours before removing the page from the index.

A few milliseconds of down time is not going to matter in the least.

  • Totally agree with Stephen. And If your site is not big, then checkout your site log, may be in specific duration Googlebot visit your website, so by doing maintenance on that time will be great, because Google have no idea weather your site is down or not. Marketing people making buzz on site down on SEO, which you should avoid if it is temporary.
    – Goyllo
    Jan 29, 2017 at 13:42
  • Server errors happen, no big deal if it's really short. If you can handle it ahead of time, a 503 is technically better (it's a clear temporary error), but short 500's are part of crawling-as-usual. Jan 31, 2017 at 19:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.