Yahoo!ウェブホスティング メモ

Yahoo!ウェブホスティングで、FTPを使ってみました。
正規化や301リダイレクトの.htaccessで、サーバーエラーが出たので、
やはりヤフーでは、.htaccessが使えないのか・・・ と一旦は諦めましたが、
マニュアルには、コンパネからBasic認証の設定が可能と書いてあるので、
.htaccessを書き直して転送すると、すんなり通りましたw
Redirect permanent /hoge.html http://example.com/hoge2.html
転送元は、httpからではなく、ルート/スラッシュから記述。

404.cgiが設置できない・・・
カスタムエラーページ(デフォルト)設置ならコンパネから設定できる模様。
これを作ってから、FTPで接続編集出来るのだろうか?
自作のCGIは使えないようで、 /cgi-bin/が隠れて、
フォームなどは、コンパネから各部品を設定するようです。
(ん?もしかして、.htaccessで新規CGIを動かせるかも!?)

ライトプランで、月980円。自由度も容量も低いのに他より高めです・・・

追記:
404.htmlページで良いなら、
/custom_error_page/404.html を作成してから
.htaccess で ErrorDocument 404 とすれば良いようです。


FC2カート 背景画像の不具合

2012/5/17日頃から
FC2ショッピングカートの背景画像やCSS画像が表示されない・・・
画像サーバの不具合かと思ったが、画像URLを直アクセスすると表示される。
数サイトで調べてみると、
表示されるカートと表示されないカートがあって、
昔から登録していたカートだけが表示されず、
新しいカートの画像は表示されていた。

※ CSSの仕様を同じにしていたから、なんとも不思議な話だ。
しかし、本日から新しめのカートのCSS画像も表示されなくなった。

FC2カートのCSS画像が表示されない原因

  • FC2カートの画像ディレクトリが変更になった
  • 外部CSSの画像を相対パスにしている

ショッピングカートなので、SSLを考慮した相対パスのサイトが表示されず、素人さんが良くやるSSLを考慮しないで絶対パスのサイトではCSS画像が表示されている。(当たり前だが)

新規で画像を登録してみると、
/cart-imgs.fc2.com/upfile/〜〜〜 となり、
以前とは別のディレクトリに登録される・・・
(FC2のお知らせにすら掲載されていない。 当然、メール連絡も無い)
以前に登録した画像は、以前のディレクトリのままでも利用できるが、
いつまで継続利用できるか不明?

SSLを考慮するのは必須なので、
CSSを書き換えて、とりあえず問題を回避したが、
また、変更があるかもしれないので、落ち着くまで様子見ですね。
統一するために全てを書き直すのはかなり面倒かも・・・


スピーバーでCGI

Speeverは初設定だったのですが、初期ディレクトリが分かり難い・・・

Speever SS-10プランのCGI
全スクリプトは cgi-bin ディレクトリ内でのみ実行されます。
(PAマニュアル)

という事で、
CGIは、/cgi-bin/ディレクトリに設定しなければいけません。
セットのCGIだったので、ローカルでの設定変更にも時間が掛かります。
更に、/cgi-bin/に設置してみたものの一発で動かなかった・・・
(有識者の解説サイトなども無いようですし)
パーミッションを変更しながら動作確認するのも時間が掛かるので、
/httpdocsに放り込んで.htaccessでCGIを有効にしました。
AddType application/x-httpd-cgi .cgi .pl

共有SSLが月額420円の有料だそうですが、
仕様表のSSL欄で、仮想専用サーバーが「有料」になっていて、
共用サーバーが「○」になっていますから無料って事でしょうか?
CGIの管理画面で利用したいけど厄介です。

ちなみに、ドメイン10円キャンペーンをやっているようですが、
今回10円で取得したとしても、gTLDドメインが通常3,990円とか移管料3,990円だから、2年目には既に他社より高い事になるでしょう・・・ 単純な餌ですかw


カラーミーショップの持ち込みサブドメイン

カラーミーショップにムームードメインの持ち込みサブドメインで運営する場合の覚書

カラーミショップの初期アカウント(URLアドレス)は、
http://アカウント.shop-pro.jp/となりますが、
運営会社のサブドメインを利用するよりも独自ドメインやメインサイトのサブドメインの方が何かと良いでしょう。
その為には、カラーミーの
「持ち込みサブドメイン」という仕様を利用しますが、
この方法は、同系列のムームードメインの利用が条件の様です。
(抱き合わせ商法ですね・・・)

  1. ムームードメインでドメインを契約
  2. カラーミーショップでカートを契約
    (レンタルサーバを借りる場合も契約)
  3. 契約内容をメモ・プリントしておく
  4. WHOIS情報変更
    • お客様の情報を公開
    • メルアドを新規設定
    • 下部のWHOIS情報変更変更ボタン
  5. 新規ドメイン取得やサブドメイン設定
    http://shop-pro.jp/manual/?mode=domain_manual
    https://admin.shop-pro.jp/?mode=domain_manual
  6. まずは、カートで利用するサブドメインを取得し、
    持ち込みサブドメインの設定とサブドメインのDNSを設定する。
  7. ネームサーバーの設定
    ムームードメインのネームサーバー設定
  8. ムームーDNSセットアップ
    ムームードメインのDNS設定
  9. ムームーDNSセットアップ
    ムームードメインのDNS設定詳細
    各レコードを設定する

HTTPヘッダーで rel="canonical"

Google HTTPヘッダーでの rel="canonical" 属性に対応
(PDFファイルなどをcanonical属性で正規化)

HTTP/1.1 200 OK
Content-Type: application/pdf
Link: <http://www.example.com/>; rel="canonical"

HTMLに馴染みの無い方でも業務上ではPDFファイルを利用するケースが多いと思いますが、そんな企業の有益な情報をPDFで手軽に公開したり、印刷用ファイルとして重複公開しても良いかも知れません。
その際の重複コンテンツ対策がHTTPヘッダーで正規化するという事です。


URLの正規化でGoogleに誤審された。

重複コンテンツ対策、被リンク分散対策

数カ月後に新規オープン予定の通販サイト(構想中)を預かり、
ドメインだけ先に新規取得しておくという事で、
ドメイン取得と同時に、簡易テキスト1ページを公開しておきました。
(新規インデックス調査も兼ねる事ができます)

ウェブマスターツールもURL登録もせずに放置。
※ 当然、他からの被リンクも無し(後日whois関係から有るでしょう)
毎週、Google検索でインデックス調査する予定が、
すっかり忘れてしまい、36日経過していました。

ドメイン名で検索すると、インデックスされていて、
キャッシュの日付けは、6日前でした。
ちなみに、
2語の複合キーワード検索では圏外、3キーワードでは5位で検索されていた。

「rel="canonical"」は指示か?提案か?

URLの正規化でGoogleに誤審された。
問題は、このドメインの運営URLが、www.ありの予定だったので、
.haccess と rel="canonical"を設置し、www.ありに正規化
なんと、www.無しでインデックスされた!

もしや、両方でインデックスされているのでは?と調査しましたが、
www.無しドメインしかありませんでしたし、
www.無しURLでアクセスすると、
www.有りURLにリダイレクトされるのでミスでも無い。
RewriteCond %{HTTP_HOST} ^(example\.com)(:80)?
RewriteRule ^(.*) http://www.example.com/$1 [R=301,L]
<link rel="canonical" href="http://www.example.com/" />

まだ、本ローンチの状態では無いので、
今は全く構わないのですが、Googleでは正規化を
「301リダイレクトやcanonical属性」と謳っていますが、
やはり例外もあり、GoogleBot君も完璧ではないようです。
Google、Yahoo!、Microosftの大手検索エンジン各社が、
URL正規化タグの導入発表が、2009年の2月

rel="canonical" リンク要素は絶対的な指示ではなく、ヒントとしてみなされますが、Google では可能な限りこの要素を追跡します。

むむ? 逃げ口上にも聞こえますが、
確かに、Googleが当時のYSTやMSNより導入も対応も早かった。
canonical属性は、単なるヒント程度だと言う人も居れば、
301リダイレクトよりも強力だと言う人も居ます。
マット・カッツ氏は、「301を使うべき」と言っているし、
http://www.google.com/support/webmasters/bin/answer.py?answer=139066,
http://www.google.com/support/webmasters/bin/answer.py?answer=139394
曖昧だから、
両方設定してるんですが・・・


後日、ウェブマスターツールでの正規化や
サイト内リンク(グローバルナビ)を絶対パスで設置すれば、
解決する事でしょうが、ちょっと意味不明な挙動でした。


XREA,CORESERVER 302,301リダイレクト

XREA,CORESERVERで、マルチドメインのディレクトリは、
コントロールパネルのドメインウェブの設定で、
一般的には、
各ディレクトリを2つ作る訳ではなく、1つにする。
XREAドメインウェブ
この場合、「NoDir ?」にチェックを入れた方を一方に転送。
そうする事で、
.htaccess未設定でもサーバサイドで、簡単に、
「www.有りのサブドメイン」と
「www.無しのドメイン」が正規化になるので、
デジロックのサーバは、とても便利な仕様だ!と感心していた。
当然、
検索インデックスでも問題無く正規化され、
他方がインデックスされる事も無く、上位表示もされていた。
※ 被リンクやウェブマスターツール(使用するドメイン)、
 sitemap、canonical属性などの影響もあり正規化してたのでしょうが。
しかし、
実は、301リダイレクトでは無く、302リダイレクトだったのです・・・

301は、「恒久的なサイトの移転」で、
家が引越で「電話番号が変わりました」のNTTアナウンスの様な状態(転送じゃないけど)
302は、「一時的なサイトの移転」であり、
不在時などの転送電話(ボイスワープ)を利用するような状態。

実例で、ちょっと確認。
301リダイレクトの例
http://google.co.jp/ → http://www.google.co.jp/
http://yahoo.co.jp/ → http://www.yahoo.co.jp/(ちょっと怪しいが)
302リダイレクトの例
http://www.google.com/ → http://www.google.co.jp/
これは、google.comが、米で実在する訳だから、
日本のgoogle.co.jpへ転送する方がユーザーには優しく、
この場合は、302が正しいでしょう。

Yahoo 基本事項 リダイレクトとは? でも、
ウェブマスター ツール ヘルプ サイトの移転 でも、
Google マット・カッツ氏も 301リダイレクトを解説・推奨している(英語なので?)

これらの事と、勝手な自己解釈を踏まえると、やはり、
XREA,CORESERVER で設定していた方法は、間違っていたのだろうか・・・

では、 XREA/CORESERVER で、www.の有り無し両方を設定する場合には、
面倒でも、「NoDir ?」にチェックを入れずに、
XREAドメインウェブ2
2つのディレクトリを作る必要があるでしょう。
しかし、両方のディレクトリに同じファイルを
わざわざ置くなんて事は、現実的に有り得ない話ですし、
ドメインウェブで同期設定をするのも抵抗があるから、
この場合には、
.htaccessで301リダイレクトが妥当でしょう。

ドメインURLのwww.有りに統一・正規化するには、各種ありますが、
Options +FollowSymLinks
RewriteEngine on
RewriteCond %{HTTP_HOST} ^(example\.com)(:80)?
RewriteRule ^(.*) http://www.example.com/$1 [R=301,L]

最後に、動作とステータスをチェック。
View HTTP Request and Response Header


サブドメイン非表示設定

レンタルサーバーでサブドメイン(初期ドメイン)が自動付与される場合、
独自ドメインを取得すると、
当然、先のサブドメインと独自ドメインの両方でアクセスできる。
このままでも特に問題無いはずですが、
たまに、検索エンジンに独自ドメインが登録されず、
たまたま、サブドメインで上位表示されてしまい、
お手上げ状態のオーナーさんもいるようで、SEO効果はゼロとなります・・・
対処法としては、(後手の対処法も色々考えられますが)
初期設定時からサブドメインをアクセス拒否すれば問題は起きない。

  1. ルート(1)にフォルダを配置し、
    独自ドメインをマッピングし、独自ドメインのルートディレクトリ(2)とする。
    ※ (2)独自ドメインのDir、(1)は(2)の上階層の初期ドメインのDirです。
  2. そのディレクトリ(2)内にファイル類を置く。
  3. .htaccessをルート(1)に置く
    ErrorDocument 403 /error.cgi
    ErrorDocument 404 /error.cgi

    ※ 良くある /404.cgi でも良いです(複合設定があれば両方置いても良いです)
  4. error.cgiをルート(1)に置く
  5. .htaccessをディレクトリ(2)に置く
    SetEnvIf Host "^www\.example\.com$" *****
    SetEnvIf Host "^example\.com$" *****
    order deny,allow
    deny from all
    allow from env=*****
    ErrorDocument 403 /error.cgi
    ErrorDocument 404 /error.cgi

    (ドメイン名、*****名は要変更)

  6. error.cgiをディレクトリ(2)に置く
  7. 【root directory】
    /www ルートディレクトリ(初期ドメイン)(1)
     ├ .htaccess
     ├ error.cgi (404.cgi)
     └ /ディレクトリ名(独自ドメイン)(2)
       ├ .htaccess
       ├ error.cgi (404.cgi)
       └ 各ファイル類
  8. 各error.cgiは、パーミション[705]などに変更
  9. 各エラー確認
ルート(1)のerror.cgiは、
一般的な「404 Not Found」で良いでしょう。
status code と REQUEST_URI を設定すれば、
サブドメインの存在をも無かった事にできます。
ディレクトリ(2)のerror.cgiは、
トップページのテンプレートを流用し、
オリジナルのエラーページを設定し、訪問者を正規URLへ誘導してあげる。
この時、各絶対パスを利用する事。
これも、status code と REQUEST_URI を設定すれば親切です。

今回の設定では、
初期のサブドメインでのアクセスは、偽デフォルトの404で返し、
ドメインの403と404は、オリジナルのerror.cgiで返すという事です。
CGIなので、ステータスコード:404で返す事が出来ます。

但し、後から独自ドメインを取得した場合は、
しばらくの間は、301にするべきですね。


ロリポップ sitemap.xml

ロリポップサーバのsitemap.xmlだけが、
何度再登録してもGoogleのステータスで完了出来ないようだ。
このsitemap.xmlは、複製でurlだけ書き替えたからミスは無いはず
今のところ、インデックス的には問題ないようですが、
今後の順位などが心配・・・

グーグル先生で調べると、
同じような症状が頻発している。
これは、ロリポップサーバ側での設定に
何か不具合か問題があるとしか言えないでしょう。
Googlebotくんを嫌っているとかw
(大昔にInktomiだかslurpだかを拒否していた事件があったらしい)

クロール速度:
リクエスト回数/秒 を 0.04
リクエスト間の時間 (秒) を 25 にすると
改善されたとの例があるようですが、何も変化なし・・・
sitemap.txtにするか悩むところですが、
あと数日だけでも様子を見ましょうか。

追記: 認識されました。
クロール速度の有効期限が90日なので、途中経過や次回も再度確認する事。