5:03

금번 소개할 툴은, 검색엔진최적화 또는 개발자의 입장에서 웹페이지의 스파이더뷰(Spider view) 즉, 검색엔진이 바라보는 웹페이지는 어떠한 형태인가에 대한 확인이 필요한 경우 이용할 수 있는 웹분석툴로서, 스파이더 입장에서의 위지윅이 아닌, 소스뷰 형태의 결과를 제공하는 툴이라고 말씀드릴 수 있습니다.

국내의 경우, 검색엔진최적화 등에 별반 관심이 높지 않은 여건이기 때문에, 스파이더뷰를 사용할만한 유저층은 대부분 W3C의 확인과 코딩오류 등을 체크하고자 하는 블로그 스킨 디자이너 및 웹어플리케이션 개발자가 주를 차지하고 있으므로, 이에 해당하지 않는 직업군의 경우에는 사실상 스파이더뷰를 접할 이유가 많지는 않습니다.

스파이더뷰는 말 그대로, 검색엔진이 해당 HTML 소스를 잘 인식하는가 아닌가의 여부를 판단하기 위한 기초툴이긴 하나, 여기에서 소개하는 툴, Web-Sniffer 라는 것은 소스뷰와 더불어 웹페이지의 헤더값에 대한 송수신 출력을 함께 지원하므로 개발자 입장에서는 반드시 검색엔진최적화를 염두하지 않는다 하더라도, 일반공통의 경우 하에서 헤더가 올바르게 출력되고 있는지를 확인할 수 있는 판단기준을 마련해 준다는 이점이 있죠.

헤더값이 검색엔진최적화에 미치는 영향 가운데 대표적인 예는 404 에러가 302, 301 리다이렉트에 있지 않을까 생각합니다.

존재하지 않는 페이지에 404 헤더를 표기하지 않는 경우와 더해, 이 존재하지 않는 페이지들이 관리한계를 벗어날 만큼 지속적으로 쌓여가는 경우 검색엔진은 해당 웹사이트에 분명한 페널티를 적용시킵니다.

아울러, 302 리다이렉트를 지속적으로 남발하는 페이지가 다수 존재하는 경우 또한 검색엔진최적화에 있어 상당한 불리점이 아닐 수 없긴 마찬가지이고요. (단, 301리다이렉트는 검색엔진최적화에 도움이 됩니다.)

따라서, 자신이 만든 웹페이지가 올바르게 404, 302, 301 헤더를 송신하고 있는지, 검색엔진 및 브라우저들은 이들 헤더값을 올바르게 인식하고 있는지를 판단하고자 하는 경우에 본 Web-Sniffer는 매우 유용한 쓰임새를 갖게 된다고 볼 수 있습니다.




위 이미지는 웹스니퍼를 통해 http://towons.kr/blog 에 대한 스파이더뷰와 헤더출력을 요청한 예입니다.

상단의 박스 첫머리에 "본 페이지는 영구적으로 301 리다이렉트됨" 이라는 문구가 나옵니다.
웹사이트와 다르게 블로그들은 대부분 httpd.conf 에서 주소별 리다이렉팅을 실시하는 구조를 갖기 때문에 올바르게 출력되야 할 블로그라면 위와같이 블로그의 첫페이지가 반드시 301로 나와야 검색엔진최적화에 불이익이 없습니다.



위 이미지는 여타의 웹사이트들보다 분명 검색엔진최적화를 잘했을 것이라고 생각하는 http://www.seo.com 에 대한 스니퍼를 요청한 결과입니다.

앞서 이야기한 바와 같이, 블로그가 아닌 웹사이트인 경우 헤더값은 반드시 200 이 되어야만 합니다.

여기에 더하여, 위 사이트의 경우 Cache-Control 이라는 메타태그를 사용해서 no-stoe, no-cache 등의 명령들을 통해 검색엔진최적화에 보다 접근할 수 있는 힌트들을 제시하고 있다는 점도 눈여겨 볼 수 있고요. (Pragma도 포함됨)

직접 웹스니퍼를 통해, 위 사이트의 URL을 기입하여 소스뷰를 해보면 SEO.COM이 검색엔진최적화를 위해 차용한 태그들과 관련하여 더욱 자세한 정보들을 얻을 수가 있는데, 대표적으로는 아래와 같은 것들이 포함되어 있음을 확인할 수 있습니다.


검색엔진최적화를 위한 가장 좋은 길은 사실상 특정 키워드와 관련하여 높은 순위를 먹고 있는 남의 사이트를 하나하나 까보는게 최적의 답입니다. 물론 INNER SEO 만 그런거고, OUTER SEO는 또 다르지만요 (OUTER SEO는 대개 인바운드링크가 주 골자)

무튼, 검색엔진최적화를 생각한다면 일단은 내 사이트의 오류처리(헤더)가 제대로 수행되고 있는지, 검색봇이 잘못 파악하고 있는 HTML코드는 없는지를 확인하는 차원의 일환에서라도 웹스니퍼는 가끔씩이나마 반드시 사용해 보실 것을 권유드립니다.

------

결론인즉, 스파이더뷰는 검색엔진최적화에 있어 빼놓은 수 없는 툴가운데 하나라는 사실?

 
--------------- 웹서버의 자동 실행할 스크립트 작성 -------------
/root아래에 backup.sh 이라는 파일을 만들어 놓고 백업 명령어를 다음과 같이 주었다.

#!/bin/bash
/usr/local/mysql/bin/mysqldump -uroot -p***** mysql > mysql_db_bak_$(date +%Y%m%d).sql
/usr/local/mysql/bin/mysqldump -uyanemone -p***** yanemone > yanemone_db_bak_$(date +%Y%m%d).sql
mv *.sql /backup
tar cvfpz /backup/html_bak.tar.gz /var/www/html
tar cvfpz /backup/yanemone_html_bak.tar.gz /home/yanemone/public_html
tar cvfpz /backup/dichang_html_bak.tar.gz /home/dichang/public_html

find /backup -ctime +3 -exec rm -f {} \;



---------------- 백업 서버의 자동실행 스크립트 작성 -------------------

백업 서버에서는 웹서버가 생성한 자료를 가져 오기만 하면 된다.

#! /bin/bash

rsync -avz 211.57.173.129::SU1/ /backup

/usr/local/mysql/bin/mysqldump -uroot -pxxxx mysql> king_mysql_db_backup_$(date +%Y%m%d).sql
/usr/local/mysql/bin/mysqldump -uyanemone -pxxxx yanemone> king_yanemone_db_backup_$(date +%Y%m%d).sql

find /backup -ctime +3 -exec rm -f {} \;

tar xvfpz /backup/htm*.gz /backup
tar xvfpz /backup/yanemone_html*.gz /backup

cp -r /backup/var/www/html/* /var/www/html
cp -r /backup/home/yanemone/public_html/* /home/yanemone/public_html

원문참조 : http://phpschool.com/gnuboard4/bbs/board.php?bo_table=tipntech&wr_id=14007&sca=&sfl=wr_subject%7C%7Cwr_content&stx=db+%C0%DA%B5%BF+%B9%E9%BE%F7&sop=and

경우에 따라, 404에러에 대해 아파치가 기본적으로 보여주는 에러페이지가 아닌, 개별적인 커스터마이징을
하고자 하는 경우가 생기게 마련인데..
이때는 /etc/httpd/conf/httpd.conf 를 열어서 아래와 같이 바꿔주시기 바랍니다.

httpd.conf

버추어호스트에 물려놓은 도메인마다 개별 설정하는게 좋습니다. 서버에 물려 있는 모든 도메인에 동일한 404를
보여주려는 목적이라면 그냥 기본 404에러페이지를 쓰는 것도 나쁘지 않으니깐요.

남은 일은 error404.php 라는 파일을 만들어서 서버에 올려두는 일뿐입니다.

error404.php

404에러가 났을때 만약 에러페이지로 보내지 않고, index.html 과 같은 메인페이지로 보내고 싶다면
ErrorDocument 404 /home/domain/error404.php 를
ErrorDocument 404 /home/domain/index.html 로 바꾸셔도 괜찮습니다.