I see many great videos online almost on a daily basis and it still blows my mind how some of these videos can be completely un-optimized when it comes to getting them to rank in search results.

Just randomly submitting a video without any thought whatsoever into YouTube or Vimeo and not really taking the time to truly optimize the components of that video submission is a big disservice to your online efforts to market yourself or your business through the internet. A video submission is like any other web page bouncing around in the search results and requires some SEO efforts to increase its potential to be found through search engine optimization labors. Often times a title and description of a video will act as the page’s meta title tag and meta tag description. If you use very generic or cutesy titles during your video submission you are only hurting your potential to be found by your audience through organic listings. Read more…

The Distributed Configuration Files, named as .htaccess, is the most reliable method to redirect webpages or even a website. This is the most secured and fastest redirection in some cases. Please note, this file works only with Apache installed on a Linux Server.

htaccess Redirect

htaccess Redirect

Here is complete guide on how to redirect webpages using .htaccess files. But, there’s something you should know..

  1. .htaccess files works only with Apache installed on Linux Servers
  2. You should put the .htaccess file in document root to make it work.
  3. Moving the configuration to httpd.conf file (if you have access to server’s main configuration file) will significantly improve the performance.
  4. 301 means the page is moved permanently while 302 means moved temporarily. 301 redirection also preserves backlinks and PR if there are any.

Let’s get started:

Redirect a single webpage

  • For a page that resides in same directory
    Redirect 301 /oldpage.html /newpage.html

    For a page that resides in a different directory (use absolute path if necessary)

    Redirect 301 /oldpage.html /new/folder/newpage.html

    For a page on different domain

    Redirect 301 /oldpage.html http://www.newdomain.com/newpage.html

Redirect an entire website

  • Place the .htaccess file in old domain’s document root
    Redirect 301 / http://www.newdomain.com/

Redirect domain.com to www.domain.com

  • This is to redirect the non www version of the website to the www version. Requires mod_rewrite to be installed.
    Options +FollowSymLinks
    RewriteEngine on
    RewriteCond %{HTTP_HOST} ^yoursite.com [NC]
    RewriteRule ^(.*)$ http://www.yoursite.com/$1 [L,R=301]

Redirect www.domain.com to domain.com

  • This is to redirect the www version of the website to the non www version. Requires mod_rewrite to be installed.
    Options +FollowSymLinks
    RewriteEngine on
    RewriteCond %{HTTP_HOST} .
    RewriteCond %{HTTP_HOST} !^example\.com
    RewriteRule (.*) http://example.com/$1 [R=301,L]

Redirect index.php or the index.html to Domain Root

  • This is to force the document root as your website root. This is helpful to avoid duplicate homepage. Requires mod_rewrite to be installed.
    Options +FollowSymLinks
    RewriteEngine on
    RewriteCond %{THE_REQUEST} ^[A-Z]{3,9}\ /.*index\.php\ HTTP/
    RewriteRule ^(.*)index\.php$ /$1 [R=301,L]

You probably have noticed that the results are not identical when a same keyword is searched using different browsers.

Why is it so? Does Google takes the user’s browser type in consideration while delivering the search results? May be or may be not.

Google

Google

It’s a question that was asked to Matt Cutts. His reply is actually interesting. The results do differ if you are logged in with your Google Account. You’ll see results depending on your browsing history when logged in while the normal listing will come up when you are not logged in. That figures.

Another this that matters is some of the browser’s functionality. Last year, Google started to use AJAX to show the SERP. The page was loading lightening fast on Firefox while in the IE and Safari were loading the pages with old system. But all of them eventually got that AJAX support.

Lastly, Matt told that Google is now testing something with the browsers and they are calling it “Bucket Testing” or “Cookie Testing”. So, the results might get a little different depending on which browser you are using, whether you are logged in or not, which cookies you have stored in your browser and all that short of stuffs.

Are these all the caffeine effect? Or just the test of the new algorithm? Either way, this surely going make the SEO harder. What can we expect next? Surely, different SERP from different OS and platforms.

xCache is one of the fast, stable and widely used PHP accelerator and opcode cacher like APC (Alternative PHP Cache) and eAccelerator. It works by caching the compiled bytecodes form PHP scripts to avoid the overhead to parse and compile PHP source code on every page request reducing the server loads and boosts the performance of PHP scripts by increasing the pageload speed by 10 ~ 20 times.

The latest version (1.3.0) of xCache is compatible with latest PHP versions (from version 4.4 to 5.3) installed on Linux servers. There’s a unstable version available (Version 2.x), but that should be used for developing purpose only.

Let us install and activate the xCache from it’s source. This is easy and shouldn’t take more than 10 to 15 minutes. You need to be logged in as root and have SSH access to install. If you are on a VPS or Shared hosting, ask your host to install it for you.

1. Login to the server uaing SSH with root access

2. Go to local source file’s directory
cd /usr/local/src

3. Download the xCache Source Files
wget http://xcache.lighttpd.net/pub/Releases/1.3.0/xcache-1.3.0.tar.gz

4. Extract the TAR archive
tar -zxf xcache-*.tar.gz

5. There will be a new directory created under “/usr/local/src” with the xCache version name. Go to it
cd xcache-1.3.0

6. Start PHP Building
phpize

At this point, you can choose to build xCache in another directory, like under “modules/xcache” directory. If so, create a directory called xcaxhe under “/usr/lib/httpd/modules/” and cd to it.

7. Configure and Enable the xCache (enter the full path to xCache source directory if you are installing it outside of the source directory.)
/xcache-1.3.0/configure –enable-xcache

8. Compile the source
make

9. Install the xCache
make install

If everything went okay, the installation will be done. Note down the paths to xcache.so file.

10. xCache now need to configured in php.ini file. Normally its located in “/usr/local/lib” directory. You can also use “locate php.ini” command to locate it. You can use “pico” command to edit the php.ini file, but the best solution is to use a windows based tool called WinSCP.

Put the following into bottom of your php.ini file

[xcache-common]
;; install as zend extension (recommended)
;;zend_extension = /usr/local/lib/php/extensions/no-debug-non-zts-xxx/xcache.so
;; install as zend extension with thread-safe
; zend_extension_ts = /usr/local/lib/php/extensions/non-debug-zts-xxx/xcache.so
;; install as PHP extension (extension_dir must be set to the full path to xcache.so)
extension = /full/path/to/xcahe/installation/xcache.so

[xcache.admin]
xcache.admin.user = "admin"
xcache.admin.pass = md5($your_password)

[xcache]
xcache.shm_scheme = "mmap"
xcache.size = 16M
xcache.count = 1
xcache.slots = 8K
xcache.ttl = 0
xcache.gc_interval = 0

xcache.var_size = 0M
xcache.var_count = 1
xcache.var_slots = 8K
xcache.var_ttl = 0
xcache.var_maxttl = 0
xcache.var_gc_interval = 300

xcache.test = Off
xcache.readonly_protection = Off
xcache.mmap_path = "/dev/zero"
xcache.coredump_directory = ""
xcache.cacher = On
xcache.stat = On
xcache.optimizer = Off

[xcache.coverager]
xcache.coverager = Off
xcache.coveragedump_directory = ""

11. Restart the apache webserver
/etc/init.d/apache* restart

12. Ensure that xCache is installed, loaded and working by looking at your phpinfo page. There should be a new block for xCache with opcode cache enabled.

xCache

xCache Block