  |
はてなキーワード: robots.txtとは
ウェブマスター オフィスアワー 2019 年 10 月 02 日 メモ（※所々抜け漏れあり）
https://www.youtube.com/watch?v=bBurTQBqhS0
11/25 Webmaster Conference Tokyo：今週か来週の早い段階で情報を公開する予定
最新情報への対応や常に変動するランキングに対応させるためのもの
「何かまずいところがないだろうか？」という視点でサイトに着手するのは不要
客観的にいいのか悪いのかを知るために定期的なユーザーテストの実施とか、
お互いにレビューし合う習慣を付けるとか
品質評価ガイドラインとかE-A-Tとかは個人的には見なくても良いと思うが、
Q.RankBrainにおける更新性や更新の有無による効果はあるのか？
A.オフィスアワーでランキング要素の可能性について言及するのは難しい。言えることはコンテンツの内容を改善してくださいということだけ。もし、更新性が影響すると言ってしまうとみんながそっちに走ってしまうので。
Q.被リンクではページランクとドメインランクのどちらを重要視していますか？
A.ショートアンサーとしてはどちらでもありません。
仮にドメインランクが重要ですと言ったら何が起こるでしょうか？オールドドメインの買い占めが発生してしまうでしょう。
例えばコンテンツの質を見るに、Wikipediaに関連リンクを貼られるとかそのくらいの影響力があるのかなどを見てみると良いでしょう。
筆者注：
【図解】グーグルのリンク評価20の原則【2019年版】（前編#1～#10） | Moz - SEOとインバウンドマーケティングの実践情報 | Web担当者Forum
https://webtan.impress.co.jp/e/2019/09/30/34042
初心者必見!SEO対策の基本を5分で完全解説【2019年最新版】
https://emma.tools/magazine/seo-basics/
↑これら記事とか？
A.Googleのアルゴリズムも完璧ではないので、アップデートで再評価される可能性はある。
メインのクエリでユーザーが自身のサービスが頭に浮かぶような存在になれるかどうか。
Q.robots.txtでブロックしていないURLなのに、カバレッジでrobots.txtでブロックされていますというエラーが出る
A.色々確認中ではありますが、私が調べた範疇では問題ありません。Search Consoleのフィードバックも送ってください。その際、スクリーンショットだけではなく、テキストで問題点も添えてください。
Q.サイト内画像をサムネイルとして表示したい。Googleが推奨する方法がありませんか？
A.特にそのやり方については公開はしておりません。Googleが良いと思った画像だけを採用します。
強いて対策を言えば、画像のヘルプを参考に画像の情報をGoogleに伝えるようにしてください。
A.確認しましたが、Search Consoleに表示されています。
タイムラグがあるかもしれませんがDisallowされていませんか？確認してみてください。
Q.HTTPSのSearch Consoleは追加した方が良い？重複コンテンツになりますか？？
A.追加した方が良いです。
重複コンテンツによって、起こるのはどちらかのコンテンツが上位表示される可能性があるということ。
共倒れになるということはありません。
そのクエリで頭に浮かぶくらいの存在になっているかどうかです。
Q.セパレートURLにおいてMFI後のcanonicalURLの設定について
正規化とは同等のページ内容のURLが複数あるからこそ行うもの。
canonicalよりも、リダイレクトでやってみてはどうでしょうか？
Q.検索パフォーマンスのデータの収集開始タイミングはいつから？？
A.基本的には登録前のデータも取れるはずですが、違うケースもあればフィードバックで教えて下さい。
Q.Search Consoleのプロパティへの表示について、所有者として確認されてから６日経ってもプロパティに表示されていません
A.何らかの判断で時間がかかったのだと思います。通常は数日ですが、遅れたのは新規サイトであることが要因である可能性があることです。なにか不具合ありましたらSearch Consoleへフィードバックをぜひお願いします。
A.かなり困っているご様子ですので取り上げましたが、当フォーラムでは対象外の話題ですのでウェブ検索フォーラムへ送信願います。
Q.max-image-preview robots meta の値を確認するには？
A.まだ反映されていないのでもうちょっと待てば反映されます。
Q.Search ConsoleのタイムゾーンについてPTからPSTとPDTに切り替わりますか？
A.切り替わります！！
Q.ドメインを変えずにサイト名だけを変えると検索順位はどう変わる？
A.サイト名ほど大きな要素を変えてしまうのは影響すると思います。
どういうサイト名に変えるのかも重要。ユーザーにとってわかりやすくなるとかであれば、長期的には有効になるかもしれません。
Q.max-image-preview でlargeを設定するとDiscoverに表示されやすいと聞きましたがAMP対応しているだけでDiscoverに表示されやすくなりますか？
A.AMPでもmax-image-previewでlargeでもどっちでも対応可能です。
Q.クロールエラーが特定できない件について、１月のオフィスアワーにてホスティング会社に相談してみては？との回答で、のち、６月に検証中とのことでしたがあれからいかがでしょうか？
A.あまり気にされなくても良いです。ただ、間違ったエラーが表示されないようにするためにエンジニアも調整中ではあります。
こういうエラーに気づかれましたらSearch Consoleのフィードバックをぜひお願いします。
次回は１０月後半か１１月前半の予定です
先日30代になりました。
前々から悩んでいたんだけどエンジニアってやっぱり若手が有利。
日々新しいこと出てくるし少しでもブランク作るとえっ何その技術みたいな感じになったりする。
そんな中で30代になって、これからどうすればいいのかわからなくなりつつある。
プログラミング大好きだよ、日々出てくる新しい情報、アプリ、サービス、全てにまだ胸は高鳴る。
家に帰って得た新しい知識で新しいものをつくる、夜が更けても平気だ。大好きだから。
けれどもいつまでそれを続けていける？
どんどん増える情報量についていけない日が来る。企業だって若手を取りたがる。
体だって持たなくなってきた。消灯時間はどんどん短くなり知識を吸収する時間が減る。
焦りはあるけれど体あってのエンジニア、休息を取らないわけにはいかない。
まだまだ勝負はできる。
勢いのある企業で朝から夜までプログラミングに浸り（設計とか他もあるけど）、
同時に選択もできる。それは中小企業や大企業の保守的なポジションについて、
日々新しいこともないけれど浮き沈みすることもなく、「将来」を安定された席に着く。
どっちが正しいんだろう？どっちが幸せなんだろう？
こんな時肝心なGoogleは答えてくれないから増田に投げてみる
(きっと本当に大事なことについてはrobots.txtに何か書かれていてクロールしてくれないんだ)。
https://mizchi.hatenablog.com/entry/2018/08/24/060111
これを読んでの妄想
昔のディレクトリ型検索エンジンのようなサイトを一つ作る
ここにはrobots.txtで既存の検索エンジンからのクロールを拒否しnoindexを設定した上で、さらに特定の文字列をページに埋め込まないと掲載できないようにする
ユーザーが検索したときは登録順に表示するかランダムに表示するかが選べるのみで、サイト側にSEOを考慮させない
これをOHTTP(OverHTTP)プロジェクトと呼ぶことにする
ここまで書いたけどこれTorで良いんじゃね
id:sakuragaoka99 さんへ。どうやら私のブックマークコメント ( http://b.hatena.ne.jp/lispmemo/20161103#bookmark-306500639 ) に対するコメントのようなので、ここで私の見解を説明しておきます。
id:sakuragaoka99 さんが、http://b.hatena.ne.jp/entry/306500639/comment/sakuragaoka99 で説明しているとおり、
という意見はそのとおりです。私もそう思います。自分が考えた結果や同意できる意見や反対意見などは、すべてその人の判断に基づくものなので、最終的にその人の責任になりますが、自由に意見を表明するべきだと思います。
ただ、私には、らくからちゃ( id:lacucaracha )さんのブログの会計に関する記事はかなりあらが目立ち、正直言って初学者には全くお勧めできません。私以外の何人かの(会計を知っているような方だと想像しますが)の人も同様に思ったようで、 らくからちゃ( id:lacucaracha )さんの『原価計算の基礎と基本について全力でまとめてみる』 http://www.yutorism.jp/entry/costing への指摘が、 http://anond.hatelabo.jp/20160517150742 から続く、結果として長大なエントリの羅列になったのでした。
これを会計を知らない方にむけて喩えて言うならば、料理のプロを自認する人が、コショウを手に持って、
と知らない人に向けて説明しているようなものです。どうもらくからちゃ( id:lacucaracha )さんの会計の記事は、「コショウ」と「塩」と「砂糖」を、ひどいレベルで混同していると見受けられるようなレベルなのです。いずれの調味料も料理に使うものではありますが、だからといって、その説明が正確だとは言えません。
以上のように、らくからちゃ( id:lacucaracha )さんの会計の記事は、私にとっては見過ごせないくらい大きな間違いが含まれていると感じているのですが、他の人はそうは思わずに、信用することもあるでしょう。(ただ、私が言いたいのは、単に「すごい大きな間違いがあるよ」というだけで、それを「読むな」などとは言っていません。「読むと混乱するでしょう」と言っているだけなので、その点ご注意願いたいところ。)
ちなみに、私が http://anond.hatelabo.jp/20160520110650 にて指摘した、
らくからちゃさんのおっしゃる『ある生産要素の投入と生成物との関連性』というのは、具体的に何を意味していますか？ 現時点でググったけれど、ちょっとわかりません。(ウェブ魚拓を取ろうとしましたが、robots.txtがあるという理由で取得できませんでした。それゆえ結果が固定できませんが、その点が問題にはならないと思います)
などという点について、らくからちゃ( id:lacucaracha )さんからの回答が現在も無いということを、この場を借りて再度言及しておくことにいたします。
これは、らくからちゃさんが書いた http://anond.hatelabo.jp/20160519220812 への返信です。(いままで「らくかちゃ」さんだと思っていましたが、「らくからちゃ」さんですね。お名前を間違ってしまってすみませんでした。このエントリの時点で気がついたので、過去のものはログの保管の観点から修正してません。そちらについてはご寛恕を請う次第)
http://anond.hatelabo.jp/20160519220812 にて、らくからちゃさんは
と、いう話を書こうと思ったのですが、もしかして消されちゃいました？（更新ボタン押したら原文が見えなくなっちゃったのですが）
と反応されていますが、この話は、 http://anond.hatelabo.jp/20160518115232 で私と、もともとは、http://anond.hatelabo.jp/20160517150742 で私では無い方が指摘した点に対する返信ですね。(らくからちゃさんは勘違いで消えてしまったと思ったようだけど、消してません。ずっとそのままの状態で在ります)
http://anond.hatelabo.jp/20160518011455 で、らくからちゃさんは、
それぞれの生産形態・管理方法に合わせた計算方法を選択すべきである。では、総合原価計算と個別原価計算をどのように選択するべきであるのか
という点を踏まえつつ、
こういった生産体系にて『ある生産要素の投入と生成物との関連性』が明確である場合、個別原価計算法は原価管理の観点からも有益な情報を得ることが出来る。
一方、個別原価計算が不向きなのは『ある生産要素の投入と成果物との関連性』が不明確である場合、例えば中間品にストックポイントが置かれる場合だ。
(略)
という説明をしてますが、らくからちゃさんのおっしゃる『ある生産要素の投入と生成物との関連性』というのは、具体的に何を意味していますか？ 現時点でググったけれど、ちょっとわかりません。(ウェブ魚拓を取ろうとしましたが、robots.txtがあるという理由で取得できませんでした。それゆえ結果が固定できませんが、その点が問題にはならないと思います)
自分は『ある生産要素の投入と生成物との関連性』とは「『製品との関連における分類』を意味する」と読んで、「直接費/間接費の違いに応じて、個別/総合原価計算を分けるのか？、そんなことないでしょ・・・」、と理解した結果、
受注生産品でも間接費の配賦はあるよね
と、前提知識の確認をしました。で、この点については私とらくからちゃさんの間で誤解が生じていないようです。
その説明の後で、 http://anond.hatelabo.jp/20160519220812 で、らくからちゃさんは、
ここで『総合』『個別』というのは、明示的な基準があるというよりも、あくまで程度の問題と考えることが出来ます。工程の単位を限りなく小さくすれば個別原価計算に近づきますし、逆に指図の単位を限りなく大きくすれば総合原価計算に近づきます。
と説明していますが、個別/総合原価計算は、工程の単位の程度問題(？)ではなくて、製品を生産するときに、
とするべきものあるはずですよね？ つまり、製造の単位が1か、それ以外か。(私としては、工程の製造単位が1に近づいたとしても、2単位であれば、それは総合原価計算だよね、という点を確認したい。それゆえ、工程に応じて前の工程では総合原価計算で計算していたが、次工程では個別原価計算で計算する、といったようなことがあると思いますが、その区別は、各工程において製造する仕掛品(第一工程の仕掛品であれば、第二工程に振り替えられたときにはそれが前工程費となりますが)を「一単位としてみるか/(そうではなく)2以上の単位とみて、製造しているか」で分けるということです)
個別/総合原価計算の説明はそういった「製品の製造単位が1か、そうでないか」という点から説明でするべきではないのかな。
この点については、http://anond.hatelabo.jp/20160517150742 で、(←は自分ではない方が書いた増田です)
実は、個別原価計算は、通常、個別に把握しやすい『個別的製品』の原価管理に使うんです。よく出てくる例えは受注生産の建物や船舶ね。
一方で総合原価計算は、単一製品を『大量』に『反復継続して製造』する場合に有効な原価管理で、例えはまぁカレーでオッケイ。もっとイメージしやすくいうと製鉄工場とか石油プラントね。
と説明していますが、これもおそらく私と同じ理解だと思います。
私と http://anond.hatelabo.jp/20160517150742 (←は自分ではない方が書いた増田です) の指摘をまとめると、
とでもなるかと思います。
これは、私が http://anond.hatelabo.jp/20160519113148 で指摘した部分です。これはらくからちゃさんが誤解されたようなので、ここで再び説明させてください。
http://anond.hatelabo.jp/20160519113148 で私が指摘したかったのは、 http://www.yutorism.jp/entry/costing の、 http://cdn-ak.f.st-hatena.com/images/fotolife/l/lacucaracha/20160515/20160515165334.png という画像が間違いであるという点です。
現時点では、↑の画像は、
┌─────────────┐ 費目別計算 │材料費 労務費 経費 │ └─┬────┬────┬─┘ 賦課（直課）│ │ │ │ ┌─┼────↓─┐ 部門別計算 │ │ │ 補助部門費│ │ │ ↓ ↓ │ │ │ 製造部門費 │ │ └───┬────┘ ↓ ↓ 配賦 製品別計算 ┌──────────────┐ │ 総合原価計算／個別原価計算│ │ 標準原価計算／実際原価計算│ │ 全部原価計算／直接原価計算│ └──────────────┘
という関係図になっていますが、製品別原価計算の分類は、本来は、以下のように、
┌─────────────┐ 費目別計算 │材料費 労務費 経費 │ └─┬────┬────┬─┘ 賦課（直課）│ │ │ │ ┌─┼────↓─┐ 部門別計算 │ │ │ 補助部門費│ │ │ ↓ ↓ │ │ │ 製造部門費 │ │ └───┬────┘ ↓ ↓ 配賦 製品別計算 ┌──────────────┐ │ 単純総合原価計算 │ │ 等級別総合原価計算 │ │ 組別総合原価計算 │ │ 個別原価計算 │ └──────────────┘
製品別計算の区分においては、生産形態の種類別によって分けるべきではないか？という点の指摘でした。
実際に原価計算基準上でもそのように分類しています。(原価計算基準の区分は 『原価の製品別計算、原価単位、計算の形態【原価計算基準19、20】｜会計知識、簿記3級・2級・1級を短期間でマスター【朝４時起き活動のススメ】』 http://ameblo.jp/studyja/entry-11483327103.html などで確認してください)
┌───────────────┐ │ 総合原価計算／個別原価計算 │ ┌─┤ 標準原価計算／実際原価計算 ├──────┐ │ │ 全部原価計算／直接原価計算 │ │ │ └───────────────┘ │ │ │ │ ┌─────────────┐│ │ 費目別計算 │材料費 労務費 経費 ││ │ └─┬────┬────┬─┘│ │ 賦課（直課）│ │ │ │ │ │ ┌─┼────↓─┐│ │ 部門別計算 │ │ │ 補助部門費││ │ │ │ ↓ ↓ ││ │ │ │ 製造部門費 ││ │ │ └───┬────┘│ │ ↓ ↓ 配賦 │ │ 製品別計算 ┌──────────────┐│ │ │ 単純総合原価計算 ││ │ │ 等級別総合原価計算 ││ │ │ 組別総合原価計算 ││ │ │ 個別原価計算 ││ │ └──────────────┘│ └────────────────────────┘
がより適切でしょう。(外枠に各種原価計算を移動させました)
これは例えていうならば、人間を何かに着目して分類したとします。仮に以下のように、
┌─────────人間────────┐ │ │ │ 国籍 日本／アメリカ／他もろもろ│ │ │ │ │ │ 肌の色 白／黄褐色／ 他もろもろ│ │ │ │ │ │ 話す言葉 日本語／英語／ 他もろもろ│ └───────────────────┘
国籍、肌の色、話す言葉で分類したとして、話す言葉の分類の中が、以下のような分けかただと変でしょ？という指摘です。(話す言葉の右側の枠が、話す言葉の分類だとします)
┌─────────人間──────────┐ │ │ │ 国籍 日本／アメリカ／ 他もろもろ│ │ │ │ │ │ 肌の色 白／黄褐色／ 他もろもろ│ │ │ │ │ │ 話す言葉 ┌─────────────┐│ │ │性別 男／女／他 ││ │ │身長 １７０ｃｍ以上／未満││ │ │視力 １．０以上／未満 ││ │ └─────────────┘│ └─────────────────────┘
話す言葉の区分の中で、性別の区分や身長の区分があると、話す言葉として「性別」という言語や、「身長」といった言語があることになりますが、そんなことはないですよね。
らくからちゃさんが http://anond.hatelabo.jp/20160519220812 で使用した言葉を使って、最も正確に表現するとすれば、
┌───────────────────┐ │ 総合原価計算制度／個別原価計算制度 │※←の枠の中は、必ずそれぞれどちらか一方を選択する ┌─┤ 標準原価計算制度／実際原価計算制度 ├──┐ │ │ 全部原価計算制度／直接原価計算制度 │ │ │ └───────────────────┘ │ │ │ │ ┌─────────────┐│ │ 費目別計算 │材料費 労務費 経費 ││ │ └─┬────┬────┬─┘│ │ 賦課（直課）│ │ │ │ │ │ ┌─┼────↓─┐│ │ 部門別計算 │ │ │ 補助部門費││ │ │ │ ↓ ↓ ││ │ │ │ 製造部門費 ││ │ │ └───┬────┘│ │ ↓ ↓ 配賦 │ │ 製品別計算 ┌──────────────┐│ │ │ 単純総合原価計算 ││ │ │ 等級別総合原価計算 ││ │ │ 組別総合原価計算 ││※←製品別計算の枠の中は、 │ │ 個別原価計算 ││ ↑の総合/個別と整合するものとする │ └──────────────┘│(あるいは、↑の総合/個別を消して、こちらでそれらを選択するだけの方がわかりやすいか) └────────────────────────┘
というように、一番上の枠の中の各原価計算の末尾に「制度」と付け加えて、適切な補足を加えるのが最も良いでしょうね。
(ちなみに、今回の例だと問題にならないかもしれませんが、この図だけを見ると、材料費、労務費、経費の矢印がそれぞれ、製品別計算、製造部門費、補助部門費にそれぞれ移動しているだけのように思われるような気もします。 今回のカレーとシチューなどの例であれば、工程別ではなく、組別であっても良い気もします。)
さらに指摘しますが、http://www.yutorism.jp/entry/costing の最後の方にある勘定連絡図は、工程や部門別の勘定が全く存在しないですね。その勘定連絡図の下で、青の太字で「『部門』の名前を明記しておくこ」ととあるので、勘定連絡図の中にそれらが無いのは、デカいミスに思えます。
http://www.yutorism.jp/entry/costing を眺めていて思ったのですが、いらすとやさんの画像は最初で使用する程度に留めて、それ以降は勘定連絡図や、標準原価計算の例ならばシュラッター図や差異分析のためのボックスを直接書いたほうが、遥かにわかりやすくなると思います。
らくからちゃさんは、 http://anond.hatelabo.jp/20160518011455 で、
想定読者は
一通り工業簿記について学習し、問題は解けるようになったが体系的な理解ができていない者
という想定を置いたのだということでしたよね？ だとすれば、わざわざ曖昧なイメージ図を最初から最後まで使用する必要性は、皆無でしょう。イメージ図がむしろ理解の妨げになっている点もあると思いますよ。そのレベルの読者を想定したとき、想定読者の理解の最低レベルは、「簿記二級の範囲の工業簿記の計算面」を理解したレベルですよね。ならば、一通り理解できているはずなので、イメージ図はさほど要らないと思います。
例えば個別原価計算や総合原価計算の説明として、蛇口とバケツで説明していますが、上の想定読者はイメージ図から何かが新たに「わかる」ようになるのでしょうか？ ここでは、主に仕掛品勘定を中心にすえて、
などといった点を踏まえて説明しなおすべきではないでしょうか。
これは、私が http://anond.hatelabo.jp/20160519113148 で指摘した部分です。この点については特に返信したいことはありません。（「原価計算基準は、今もファイリングしてデスクの上においております。」ということなので、読んでないのかなあ、と思ったくらいです）
去年の今頃は「今年こそはすごいWebサービス作るぞ！！！！！！！！！！！」って意気込んでたのに
なんかもう今日が最終日。
ということでこの12月頭から何か作ろうと考えていて、丁度年末だからということで作った。
前にAmazonの購入金額合計を出すブックマークレットが流行ったけど、それとほぼ同じ。
Amazonの今までの合計金額と、書籍とかPCとかカテゴリごとの合計金額出してグラフにする。
年末だしTwitterで「2014年のKindle購入金額内訳は...でした」とか投稿すれば
みんなつられてアクセスするはず！宣伝しなくても勝手に大ブーム間違いなし！！！！！！！！
って思ってたけど
投稿してもだれもアクセスしてくれない。待っても待ってもアクセス0。
e？嘘でしょ？？？って思ったら
のはずだったけど今度はrobots.txt見に来るクソbotしかアクセスしてくれない。
虚しさ半端ない。
というかTwitterでURLつぶやくと即効でどこぞやのクローラー巡回してくるんですね。
構成自体はクライアント・サーバサイド共にjs。EC2上でnode.js。
D3.jsのグラフ画像がsvgだからどうにかしてpngにしないとTwitter投稿出来ないのが微妙に面倒だった
投稿時にクライアント側でbase64→canvas→pngにしても良かったけど
商品のカテゴリ取得するためにはProduct Advertising API使うしかなくて
redis上にキャッシュしておいたりwebsocketで適当に進捗伝えたりした。
今回得た経験値としては
あたり。
今年は残念ながら目標不達成だったけど、いい最終日の過ごし方になったと思う。
お疲れ様でした。
ttp://archive.is/
↑ここ。
ここを使えば、
例えばこういうブコメ（http://b.hatena.ne.jp/entry/www.akitashoten.co.jp/news/201）で、
kyo_ju 出版
で？弁護士は誰がついてんの？/ちなみに魚拓を取ろうとしたらrobots.txtによりキャッシュが禁止されている、だそうです。2013/08/21
こんな恥ずかしいコメント（と、それに星つける恥ずかしい人達）に対して、
rgfx
魚拓禁止ですかそうですか http://archive.is/fgwwT 2013/08/22
前編はこちら
http://anond.hatelabo.jp/20120926165407
中編はこちら
http://anond.hatelabo.jp/20120926165533
基本的な機能とデザインが出来てきたら、細かな機能や説明ページなどの静的コンテンツも作っていきます。
８割程度出来たと思ったら、一度サーバーにアップロードして動作チェックしてみます。
たいていは上手く動作するはずですが、途中で一度チェックしておいた方が出来上がってから不具合を修正するよりは効率的です。
僕ははじめCORESERVERを使っていましたが、メールが送信できない不具合に遭遇して時間を取られました。
結局はCORESERVERとgmailの相性が悪いせい、という事で最後はさくらに移転しました。
あと、何となく動いているのが確認できたら、
このタイミングでGoogle AdsenseやAmazonアソシエイト、Ａ８やバリューコマースのアフィリエイトサイトに申し込みましょう。
特にアドセンスは申請してから使えるようになるまで１週間とかかかります。
２０１２年現在、アドセンスを含むアフィリエイトは期待するほど儲かりません。
でも、色んなWebサイトで見かけるこれらの広告の表示方法を学ぶことで、Webサービスに対する理解も深まりますし、
あと、全然儲からなくてもサイトにこれらの広告を表示しておくと、社会と繋がっている雰囲気が出て活況感が高まったり、
自分のサイトがちょっと立派に見えてテンションが上ったりします。
それぞれのプログラムの使用方法は検索すると出てきますが、敢えて本でおすすめはこの２冊。どちらも基礎です。
アフィリエイトで<得する>コレだけ!技 BEST100
サーバーに最新のファイル一式をアップロードして、入念に動作チェックをします。
core.phpのsession idをデフォルトの状態から違うものに変更したか、
全てのコントローラーのデバッグツールキットはOFFになっているか、
CakePHP本体は公開フォルダと別の階層にアップロードしているか、
htaccessの設定は間違っていないか、
などを確認します。
URLのwww付きとwwwなしはどちらかにリダイレクトさせて１つに統一できているか、
存在しないURLにアクセスされた時のエラーページに余分な情報が表示されていないか、
検索エンジン用のrobots.txtを用意、
ファビコンを設定する、
アクセス解析を設定する、Google Analyticsに登録しコードをサイトに埋め込む。
http://www.google.com/intl/ja/analytics/
Google先生に挨拶する。Google ウェブマスターツールに登録し、必要な情報を入力、Analyticsと紐付ける。
https://accounts.google.com/ServiceLogin?service=sitemaps
http://developers.facebook.com/docs/reference/plugins/like/
https://twitter.com/about/resources/buttons
その他、mixi、Google+などのボタン類も必要ならつけましょう。
全部出来たら、完成です。
Ｗｅｂサイトは作っただけでは（本当に）誰もアクセスしてくれません。
Webサービスを作ったそのあとに、「自分でもできる低コストなWeb PR方法」
http://blog.8bit.co.jp/?p=1944
こちらもチェック。
作ったwebサービスをPRできる！webサービスのリンク集サイトまとめ
http://smkn.xsrv.jp/blog/2011/11/web-service-linksite/
リリースした直後はGoogleのインデックス数も少なく、検索エンジンからのアクセスは期待できません。
検索エンジンからの流入は１ヶ月とか、時間が経つにつれ少しづつ増えてくるので気長に待ちます。
自サイトの情報のチェックはＳＥＯチェキ！とコメポンが便利。（作者のロプロスさん様様）
Ｋｏｍｅｐｏｎ！
それから、ステップ１１で紹介した本にも出ててますがフェレットも便利。
Ferret
５００円で客観的に評価してもらえるこちらも活用すると良いでしょう。
※2012年9月26日現在、このサイトは僕はまだ利用していませんが気になっています。
ホームページ評価.com
■最後に
ここまでやってみると、Ｗｅｂ開発の一連の流れが分かった気がしてきます。
初めて作ったサイトはしょぼくても、ひと通りやってみる事で
Ｗｅｂサービスの開発者としての入り口には立ったな、位には思えるはずです。
ここまでの知識をベースに、
ＳＥＯをがんばるもよし、
アドセンスやＡ８などのアフィリエイトで稼ぐしくみ作りをするもよし、です。
この記事を読んでアクションしたら、僕と同じようにアウトプットして、
そのリザルトをシェアしてトゥギャザーするオポテュニティをテラユビキタスｗ
１つ気をつけたいのは、
開発したサイトのサーバーの種類とか、CakePHPで作ってるとか、そのバージョンは1.3だとか、
そのサイトの詳細仕様は安易にこういう記事に書かないようにしましょう。
悪意のあるハッカーに攻撃の糸口をプレゼントする事になってしまいます。
この本も参考になります（まだやるか）
有益な情報をネット上に提供して下さっているWeb業界の皆さん、
それにいち早く辿り着けるはてなブックマーク、
皆さん、に感謝。
ツイッターはじめました
Google が公表したオプトアウトの方式は「アクセスポイントの所有者に対して、名称 (SSID) を末尾が " _nomap " で終わるように変更することを求める」もの。たとえば SSID が " Jitaku_AP " だった場合、無線LAN機器の設定から " Jitaku_AP_nomap " に変更することになります。
ブコメには「Googleが勝手に盗んだのにこっちがオプトアウトしなきゃいかんとは何事だ」というものが多いが、それらは問題を根本的に誤解している。
(もしかすると総務省、ストリートビュー車の無線LAN傍受でGoogleに指導。再発防止策と日本語で周知を要求 -- Engadget Japaneseの件と混同している人がいるのかもしれない。これはビーコン信号ではなく通信内容そのものを傍受していたという話で、基本的には別件である――但し、法解釈によっては同じ問題ともなり得るし、根底に共通している部分はある。これは論点がズレるので、ここでは完全に別件として扱う)
そもそもの問題は、Wi-Fiの仕様において、Wi-Fi機器のMACアドレスが強制タレ流しになっていることにある。これは例えばSSIDステルスの設定でも止めることはできない。
つまり、あくまでGoogleは垂れ流されている情報を集めたに過ぎないということである。垂れ流されているものなら勝手に集めてもいいのかという論点はあり得るが、その点についてはGoogleだけを責めても全く意味がない。誰であれ収集は可能だからだ。「しかし、他の誰がそんなことをするのか？」との反駁には「はい、PlaceEngineがしています」が答えになる。仕組みは全く同じだ。PlaceEngineは、Googleのような巨大企業でなくてもこの技術を商用レベルにまで持って行けるということを既に証明している。
つまり、この問題は「GoogleのDBから削除してもらう」だけでは全く解決しない。
(追記: どうもこの節の表現は誤解を招いたようだ。「できるからやってもいい、Googleは悪くない」という意味ではない。その議論があること、今後も必要なことは承知の上で、そもそも「できる」こと自体が根本的な問題であり、しかも各国の現行法において確実に違法な行為ではないということが重要だ。何度でも言うが、Googleを憎んでも問題は全く解決しない。あくまでここでは問題の本質を理解することと、現実的で効果的な解決方法について考えたい――もちろん、GoogleやAppleやMSなどを相手取って世界中で訴訟を起こす、というのも一つの手だろう。今のところ強制力を持ちたいなら勝訴の判例を作るしかないし、勝訴すれば抑止力を備えた最強の解決手段になる。どうぞ。)
(a) 「申し出のあったMACアドレスは削除し、今後も登録しないようにする」という対応
技術的にはすぐにでも対応可能。ただし、本人以外の手によって無差別に大量のアクセスポイントを削除するという妨害行為を防止できないかもしれない。
PlaceEngineを利用していない人（PlaceEngineの存在さえ知らない人を含む）に対して、そのような手段が用意されていることを周知しなくては問題は解決したといえず、十分な周知は困難と思われる。
新たなアクセスポイントを購入するごとに削除手続きをする必要があることについて納得しない者が、「私のものは登録するな」という主張で争ってきたら対応できない。
(b) 「SSIDステルス設定にしているアクセスポイントは、登録拒否の意思があるとみなして、登録しない仕組みとし、また、既に登録されているものは次回検出時に自動的に削除されるようにする」という対応
技術的には容易に可能。しかし、そのような仕様であることを周知しなくてはならない。PlaceEngineを利用していない人（PlaceEngineの存在さえ知らない人を含む）に対して周知しなくては問題は解決したといえない。
(c) 「暗号化設定されているアクセスポイントは登録せず、他は削除する」という対応
暗号化していないアクセスポイントは特定の相手方に対してのものではないとみなすことで、電波法59条の問題をクリアできるかもしれない。
しかし、これを採用すると登録アクセスポイント数が減ってしまい、位置の測定制度が低下する。
(d) 所有者の同意を得たアクセスポイントしか登録せず、他は削除する」という対応
まず、ブコメで要求されているような「オプトイン」の仕組みは(d)だが、これは実現性に乏しいと考えられる。どうやってオプトインするんだという問題もあるわけだが、そもそも「誰でも収集できる」のだから、個別にオプトインなど根本的に不可能であるし、無意味でもある。例えGoogleが独自にオプトイン方法を用意したとしても本質的な問題は全く解決しないばかりか、ユーザに「Googleでオプトインしなければ安心」という誤解を与えかねないという懸念もある。
(b)や(c)についてはサービスプロバイダ側の設計の問題であり、ユーザは関与することができない。
今回Googleが提案した方法は、(a)の改良型(あるいは(a)～(c)のハイブリッド)というべきものである。再掲。
Google が公表したオプトアウトの方式は「アクセスポイントの所有者に対して、名称 (SSID) を末尾が " _nomap " で終わるように変更することを求める」もの。たとえば SSID が " Jitaku_AP " だった場合、無線LAN機器の設定から " Jitaku_AP_nomap " に変更することになります。
オプトアウトという意味では、(b)のSSIDステルス法も同様である。それよりも_nomapが優れているのは、これが「うちのAPをマッピングしないでくれ」という明確な意思表示となるからだ。
SSIDステルスや暗号化をオプトアウトフラグとして扱うかどうかは単に実装に期待するしかないが、_nomapがデファクトになれば、万一オプトアウトが実装されずにマッピングされた際「俺は一般的に合意されている方法でマッピング拒否の意思表示をしていたぞ！」と法的に主張できる可能性がある。Wi-Fiの規格に変更を加えるものでもなく、この用途以外に意味を持たないことから、デファクトとして広まりやすいだろう。確かにSSID変更が困難なケースは考え得るが、しかしこれ以上に簡単な代案は私には考えられない。
解決しない。
ここに挙げたどの方法を採ろうとも、原理的に「サービスプロバイダのマナー」程度にしかなりようがないからだ。オプトインですら、である。robots.txtを無視するクローラを根絶することができないことにも似ている。そしてそれは、Googleの責任ではないし、Googleに責を負わせても全く意味がない。
最初に述べた通り、そもそもの問題は「Wi-Fi機器がMACアドレスをタレ流しにしている」ことであり、これはWi-Fiの仕様改訂で対応しないとどうしようもない。また、対応したとして、新方式へ完全に置き換わるまでには気が遠くなるほどの長い時間が必要だろう。WEPすら未だに根絶できないというのに。
また、Wi-FiはMACアドレスをタレ流しているぞ、これは防げないぞ、という啓蒙ももっと必要だろう。一般ユーザには何のことやらさっぱりわからないと思うが、それでも啓蒙しないよりはマシである。
一つ付け加えるなら、個人的には、デファクトとなり得るオプトアウト方法を提示したGoogleさんはもうちょっと褒められてもいいと思う。これはAppleやPlaceEngineが今までしてこなかったことだ。
ちなみに、Google Location Serverでは既に「2つ以上のMACアドレスがDBとマッチしないと位置情報を返さない」などの様々な対策を実施済のようである。これにより、もしMACアドレスやSSIDが漏れたとしても、その所在地をこんな方法で正確に掴むことは困難になっている。PlaceEngineは知らない。
もう一つ。この問題は、Wi-Fiだけに起こりうる問題ではない。ひろみちゅ先生は本来この問題をRFIDの普及によって起こりうる問題として予測していたそうである。この辺りもっと知りたい方はgoogle:高木浩光 PlaceEngineとかして勝手に読んでください。
PlaceEngineより、Googleの提唱する_nomap方式のオプトアウトに準拠する旨のリリースが出た。
PlaceEngineデータベースにおける無線LANアクセスポイント(AP)情報の取り扱いについて
Google社から、Google Location Service のWi-Fi位置情報データベースから無線LANアクセスポイント情報を削除するためのオプトアウト方法（SSIDに"_nomap"文字列を追記する方法）が公開されました。
PlaceEngine サービスにおいても、Google社のオプトアウト方法に準拠する形でPlaceEngine位置推定データベースから該当するAP情報を削除する運用を実施する予定です。具体的な実施時期や運用方法については、別途お知らせします。
また、PlaceEngineサービスにおいては、以前より、主にモバイルルーターなどに対応するため、オプトアウト(削除)したいMACアドレスをサポート窓口へ送付して頂く方法などをとっておりましたが、こちらについても引き続き運用していきます。（「位置推定の改善」をご参照ください）
これこそがまさにGoogleの狙った効果だ。素早くデファクトになり得る。すると次の段階として、Wi-Fi機器の製造者が設定画面に「☑位置情報サービスからオプトアウトする(SSID末尾に_nomapを付加する)」のような項目を用意することが標準化する、などといった流れに進むことも期待できそうだ。これには一層の啓蒙活動が必要になるが、十分に現実的な範囲だ。
そして、「Wi-Fiだけの問題ではない」と書いた通り、あっさり同種の別問題が持ち上がってきた。今後、この手の問題はゴロゴロ出てくるだろう。そもそもどこまでが許される範囲でどこからが許されないのかといった大枠の議論も含め、どんどん問題にして世界中で合意やルールを形成してゆく必要がある。先は長い。
高木氏が「異常」と言っているのは、一番目の選択肢が変なURLだけになっていること。
でも決して「検索サイトが変な結果を意図的に表示させた」わけではない。
技術的にはやろうと思えばrobots.txtの記述を無視して収集できるし、
でもしない。robots.txtで「しないでください」と書いてあるから。
（昔は無視して収集する検索サイトはたまにあった。今は知らないけど）
http://takagi-hiromitsu.jp/diary/20101024.html#p01
高木氏はrobots.txtが修正されることにより、「検索サイトで正常に閲覧できる」ようになった、
と書いています。また、「/robots.txt によってすべてのクローラを排除していたため、図1の「ビフォー」のように異常な検索結果になっていた。 」とも。
検索サイトってそんなに偉いんでしょうかねぇ、と思っただけ。
どのことなのかわからないけれど、「使え」って話じゃなくて「変」って話じゃなかったっけ？
robots.txtはサイトの意思表示なんだけど、それ（意思表示）が変って事なら図書館側の問題だよね。
あと、googleにとっては岡崎市立中央図書館なんて努力する程のものではないでしょう。
図書館側がどうこうするつもりもなく、よほどの苦情もなければ、特別トップに出す必要性もないし。
そんなもんだよ。
Googleの検索結果で表示がおかしい、という指摘があり、robots.txtを使え、というような話があったと思う。
でもGoogleの検索結果の表示がおかしいのなら、それはGoogleの問題じゃないの？
Googleが実質、検索サイトの標準なのかもしれないけど、Googleの検索結果の表示でトップに表示されないのは図書館側の問題というのはおかしい気がする。
Googleのサービスは色々なサイトを探し回って何かしらの基準で順番に表示させているわけだけど、その表示順で上位に行くために、図書館のＷＥＢサービスで準備しないといけない、というのは本末転倒ではないの？
企業のＷＥＢサイトで検索結果の上位に表示されたい、という企業側の思惑はあるだろうけど、公共機関については検索サイト側が努力するべきことじゃないの？
そろってるっつーかなんつーか・・・
ログイン周りなんて、フレームワーク使わなくても、４時間かかるかどうかだよ・・・セッション周り慣れている人という前提なら。
問題なのはページ数が増えたときにすべてのページに間違いなく確実に同じ処理を入れることで
それが複数人のプログラマになっても、守られること。
そうなるとフレームワークの出番ってはなし。
あとは、それこそセッションハイジャックやらセキュリティ対策が時間がかかる。
今回問題なのは、そんな、慣れている人なら、そもそも、いわれなくても入っている。最初に入れておく一般的機能がまったくはいっていないこと。
robots.txtすらおかれていないこと。普通管理画面以下は、万一に備えて、robtos.txtを置く。という知識もないこと。
そして一番問題なのは PCソフト販売会社がその程度の、セキュリティー知識もない会社に発注するほど、セキュリティー知識がないこと。
コレだとすると、発注側にノウハウが無いので、今後も、セキュリティーの向上は見込めない。
こう言っちゃ何だが、ユーザーは訴訟を起こすべきだし、PCソフト販売会社はさっさと、別なまともな会社に頼むか、
しかしなぁ、
世の中には、パスワード一覧をEXCELファイルで作っちゃって、まちがってメールで関連先に送付しちゃって大問題っていう
それでいて、操業停止になるくらい、ユーザーが離れるわけでもないんだぜ？
そりゃぁ、セキュリティーなんて向上しないし、みんな無視するよなぁ
安かろう悪かろうで、そういう業者に発注するからそういうことになるんだが・・・
真面目にセキュリティーに取り組んでる奴がバカをみる・・・
嫌な時代だよな。
ちなみにな・・・
http://mag.wb-i.net/2010_04_02.html
対処策が・・・
１．metaタグの挿入（noindex,nofollow,noarchive）
２．USER_AGENTよるSpiderの排除
なんつーかな。
そもそも、セッション持って、外部から見られないように対策すべきであって、クロールされなきゃ良いって問題じゃないと思うんだが？
それにmetaタグよりrobots.txt使えば早いのに・・・とか、突っ込みどころ満載。
これを無しで販売したそのマインドがすばらしいし
それを購入した方のマインドもすらばらいい。
起きるべくして起きた事件としかいいようがない。
つーか、こんな初歩の初歩にひっかかるようじゃ、
真面目な攻撃食らったら簡単に個人情報吐き出しそうだな・・・このプログラム。
SQLインジェクションに感染したりして・・・ｗ
