WEBサイト
　 サポート

まずやりたかったこと、サイト運営者として預かるサイトの視覚化：site2room の始まり このサイトを公開するにあたり、今まで多くの現場でのサポートをしてきたことからの想いと、それを行うことの面白さの興味・・・これが、まずやりたかったことのひとつ。 休みなしで開いている自分が管理しているサイト（お店）の視覚化だ。 コンビニの店長が自分のお店で、毎日「今日の入り」や「お店の中での利用者の動き・反応」を肌で感じながら経営をしているのと同じ、サイトの利用者の状況を表形式やグラフではない形で、手軽に確実に感じられること、それへの一つのアイデアとして、 サイトを家のように、お店のように考え、間取り図を組んで、そこにアクセスされた情報を配置することからはじめてみよう。 WEBサイトは家だ！お店だ！自分の部屋だ～ ★site2room それには、アクセスされたデータが集積している Google Analytics (GA4) との連携が必須だ Google Analytics (GA4) との連携させる仕組みの構築 Google Developer Console でこれを実現するためのいくつかの設定、そして何より、それを行うことをGoogleに伝え、厳しい審査にパスしなくてはならない それには、アクセスされたデータが集積している Google Analytics (GA4) との連携が必須だ Google Developer Console で、client id を用意したのち、申請、何度も情報の修正と再申請を繰り返し、ようやく認めてもらえた サイト自体が適正に用意されている事。プライバシーポリシーや利用規約への、GA4データの利用についての宣言も明記。 テスト環境で、実際に利用する部分を用意した後に、その詳細な手順や内容を Googleに説明するための動画を準備 何度も申請＜＞やり直しを繰り返し、ついにクリア、公開の機能として準備することができた。 これを進めるにあたり、AIの力を借りて進行することは記録しておく必要がある。従来のようにひとつづつGoogle検索で情報をかき集め、リトライを繰り返すやり方では、これほど短期で実現することは出来なかっただろう。感謝している。   会員登録していただければ、Myページに　GA4との連携を行うボタンが表示される あらかじめ　管理する「ホームページURL」を登録しておいてください。 クリックして Googleの OAuthの仕組みで了解をしていただく。 認証の完了。   あとは、認証を許可し、GA4で解析したいプロパティID をセットする プロパティIDを設定後は、画面を更新してください。 じゃこの状態で、ツールの「site2room」を開いてみよう メッセージが変っていると思います 実行してみますね site2room に、GA4から取得したデータが表示される 表示されました。 "ひんそ"な数字が並んでいることは無視してください。 （まだ　このサイト：WEBサイトサポートが認知されない事・・・この問題自体は別にそれへの対応記録をオープンに公開します） ActiveUser数の多い順、7部屋（7URL）が表示されています 各部屋に前日のデータ「２つの数字（デスクトップ / モバイル）」が表示 GA4のAPI取得では各部屋(URL)の数値は前日のものしか取れない 中央（リビングといいますか、廊下にしてはひろいですが）には、サイト全体のリアルタイムデータ表示 赤い数字、ですね その下には、リアルタイムのイベントの情報、そう、いまお客様がしていることですね 画像は SVGで構築していて、多少のインタラクティブ機能もあります。 リビング？ の右上にある　2つのアイコン　その右側をクリックしていただくと こちらは、表示回数、つまりページビューですね。 Googleの、旧版の UAからの最大変化の一つが、 データ取得のベース（ページ ＞ ユーザー行動）ですが、いままで簡単に見れていた「ページビュー」が、GA4でが少し確認しにくい。 Googleの考えていること、利用者スタンスのさらなる強化から、 ページを主体に考えていたアクセス解析ではなく、 利用者の行動や状態に重きをおいたGA4に変化したのは、理解してるしいいのですが、 それでもやはり現場では「ページビュー」は　"大きい" のですよね。 これから、site2room はどこへゆく？ site2roomは、今の段階では、ただ、四角形書いて、GA4取得情報を表示しているだけですよね？ これから？ はい、色々考えています。 でも、みなさんならもっと素敵なアイデアをお持ちかもしれない。 こんな風になれば、もっと使う！。こうしてほしい、こういうアイデアはどうなんだってのがあったら、どうかお教えください。 （あ、そういうフォームも用意しなきゃな） GA4から取得させていただいたデータには細心の注意を払っています 現時点では、 site2roomで部屋の描写画面を表示した時点で、取得したデータ自体は全て削除しています。 ※なので、再読み込みすると、もう表示はされません。 ※なので、画像での取得用ダウンロードボタンを用意しています。 今後は、利用する側のスタンスで考えると、 状態確認＞対策検討＞対策＞再確認の PDCA廻すためには、記録が必要なこともありますので、いづれ、記録しておき比較検討などもできるようにする、といったことも検討中ですが、 いづれにしてもこれらデータを弊社が保存し他で利用するなどという勝手なマネは一切いたしませんので、 ご安心ください。（信じてもらうしかない） 毎日暑い日が続きます。こういうときは、WEBサイトサポートで管理サイトウォッチをされてください では、また・・・

面白いことになった。公開1週間、Googleに登録されない。今まで以上に、本気で向かえってことだな WEBディレクターが本当に使える、現場目線サイトを・・・なんて意気込んだが、コンテンツ自体は着々と進んでいるが、未だ、Googleにちゃんと登録されてない？　色々と思いつくことはあるのだが・・・これは少し面白くなってきたかもしれない。 ぜんぶ、見せて、粛々と対応しよう。 こちらが、今の GA4。昨日少しはねたのはなんだったか？自身のデバッグか？そんなにやったっけ Google Anlytics 記録する：2025/07/19 で、こちらが、Google Seach Console：2025/07/19 お客様のサイトをあーだこーだといって、コンサルしたり創ったりしてきたけど・・・こうやってスタート悲惨な自己サイトを前にして、なぜか楽しくなるのはなんなんだろう。 基礎として行ったこと、確認。 sitemap.xml は用意して（もちろん、このサイトのツールWEBサイトの sitemap.xml 作成ツールで）、Search Console から送った WEBサイトサポート：sitemap.xml robot.txt は、ベーシックなものだがおいてある。 User-agent: * allow: / 基礎的なDOM構造も維持している 現状把握をもう少し。インデックスされてないんじゃぁ、話にならないけどね もちろん、そんな急激にアクセス来るとは思っていないし、しれっと公開で、まだ知人数人に伝えただけ。宣伝もしていない。 こんなものなのだね。今や数10億のサイトがひしめいているインターネット。小さな塵よりも小さい存在だから・・・ インデックス登録されていないのだから、当然検索に出るわけもない。 Google検索もいまは変革期だ。最初に、Googleにとって大事なお客様が紹介され（スポンサー） 次に来るのは、AIによる　回答ビューだ。 海外ではすでに、Google AI Overview（AIによる概要）は当たり前になってて、日本でも、ゼロクリック時代到来が騒がれている。 ま、このサイトの思惑・ポリシーは明確だから、特にこれで（このサイトで）食べてゆこうと思ってないから、ただただ真摯にいいサイトを創ってゆくだけなのだけど。 ただ、仕事柄、AI無視はできない、本来アナログ人間の私だが、ネット制作のプロとしては、本気でAIにもむきあってる。 "WEBサイトサポート" と探されたら、ここに確実に紹介されなければならない。AIO、GEO、だね。 お・・・脱線。 わかっているけど、順位チェックもしておこう。 はいはい、わかってますよ。これっぽっちも（ほんとか？）、期待しないで試した。 実は　順位チェッカーも途中まで創ってたんだよね・・・でも、今でもいいのがいくつもあるので、労力無駄。お蔵入りとなりました。 また脱線。 粛々と対応してゆこう。悩むより行動 Search Console で URL検査 ひどい画面だ。ライブテストして一応表示されたが、色々問題ありそうだな・ 一応もう一度　インデックス登録のリクエスト送っておく 構造化データ、ね。とても重要だが、今はそれ以前の段階だ。ちゃんと対応するから、待っていてくれ。 Search Console に新しくできた　分析機能　も試しておく。「この期間にクリックはありませんでした」・・・えぇ、わかってます。 サイトマップ（sitemap.xnl）もちゃんと送ってますよ。 コア・バイタル、か。このあたりも、いづれがつがつやりたい。 でもね・・・ひとつ気が付いたことがあるんだよね 登録されたのは、わずか3ページのみ。上等じゃないか。 ・・・それよりも 登録されたのは、わずか3ページのみ。上等じゃないか。 401 で登録されなかった・・・401エラーは「Unauthorized（未認証）」 つまりこちら側の問題 なるほどね。 今回、いろいろ計画があって、長く持ち続けた "usersupports" というドメインを使って、"website.usersupports.com" としたわけなんだけど、そもそも親の usersupports のサイトがない。"website-test.usersupports.com" は開発用のサイトだから、Basic認証かけてるし、いいんだけどね。 今回、Search Console 登録に、DNS登録で　ベースの usersupports.com で登録したからなぁ。 あ。でもどうなんだろ、DNS登録じゃない昔ながらのやり方で website.usersupports.com 登録したらどうなるんだろう？ 重複登録できるのかなぁ？ こんな機会だから色々やってみよう。あと、親の usersupports.com なんらかのページ自体が必要かもしれないな。 ん～ん、すべき方向性が見えてきた気がする。 よし、親の usersupports の基礎コンテンツを用意しよう でも　サイト自体も今日も色々やった。 シンプルなスライダーを WhatsNew 代わりにして、各ツールのデバッグも進んだ。 誰も来ないから、デバッグし易いってのはあるな。 今日はここまで。お腹減ったし・・・

少し用意したツールを紹介しよう。まずは、会員登録したら使える「管理サイト」機能 このサイトでは、WEBディレクターが本当に使える、役立てるツールを、現場目線で用意することをポリシーにしている。少しづつ紹介してゆきたいが、最初に、会員登録していただくと使ってもらえる「管理サイト」機能を。 これは、WEBツールというページにではなく、トップページに用意した3つ目のタブ「管理サイト」で用意されている。 会員登録してサインイン（ログイン）していただき、管理サイトを登録するとご利用いただける。 会員登録（もちろん、無料）して、マイページで管理するサイトを登録 サイトのURLアドレスをセットして、下部にある [ 更新 ] ボタンをクリックしてください。 ちなみに、おまけみたいな機能ではありますが、1日1回、サイト生存確認できる機能も用意してますよ。 登録後、トップページの「管理サイト」のタブを開いてみてください サイトのURLアドレスをセットして、下部にある [ 更新 ] ボタンをクリックしてください。ここからもゆけます。 最初、初回のクロール走査を行います。少しお時間かかると思うので、何か他のことをされてお待ちください。 管理サイトの基本的な状態を確認してください [基本情報]・[パフォーマンス]・[コンテンツ]・[リンク]・[SEO] の５つの視点から、簡易的ではありますが、サイトの状態をスキャンしてスコア付けされます。   スクリーンキャプチャ PC（デスクトップ）、mobile（スマホ）のスクリーンショットを配置 ５つの視点でのスコア 下にある数値は　エラー/警告(Warning)。自分で創ったシステムではありますが、このサイトの今、ひどいもんですねぇ ちょっと厳しすぎるかも。（変更するかもです）。まぁ、スコア・表示はほんとご参考程度で、それよりも提示している各要件に注視、どんどん対応してゆきましょう・・・私もやりまーす。 クリックで詳細な情報が表示されます 重要指標 [読込スピード]・[サイズ]・[重さ]・[リンク]・[OGタグ廻り] 優先改善事項 さぁ、何やりましょってことですね。どんどんつぶしてゆきましょう パフォーマンス、コンテンツ、リンク、SEO の スキャン詳細 なるべくシンプルに気にしなければならないところを端的にまとめています 再走査する　ボタンで再スキャンしますので、確認して（大事！）、対応して、スキャン・確認の PDCAの始まりですね！！ いまの WEBサイトサポート・・・ひどい状態だということはわかりました では、これからこれを　どんどん改善してゆく様子も、またオープンに公開したいと思います。 ぜひ、みなさんも管理サイト登録してチェック、サイトをよりよくするためにお役立てくださいね なお、この WEBサイトサポートでは、基本的にみなさんの詳細な情報を保存することはありませんが、この「管理サイト」は、この後の追加機能で、検査したものを時系列に把握でき、何をやった同良くなった・・・を把握できる機能を予定しており、ここのスキャンデータだけは保持しています。（退会されれば抹消されます）。暗号化して保存しています。ご了承ください。 今日はここまで。またお目にかかりましょう。

しれっとオープンしてから数日。引き続きずっと触ってます。成長させる。 このサイトでは、今もいくつかのツールを提供してて、さらに今後も、サイト運営の現場で役に立つツールを、どんどん用意したい。 安心して使ってもらうためにも、このサイトを長く利用してもらうためにも、セキュリティ対策が必要だ。こんな小さなサイト、誰が狙うか、とも思うけども、最低限はしておかなくてはね。あ、どこかのハッカーさん、狙ってやろうなんて思わないでね、お金も得るものもは何もないから。 で、こうやってその事も書き留めておけば、誰かの目に留まり役に立つかもしれない・・・   "うちには関係ないよ" は　関係ない 「この規模のサイトが、狙われるわけないでしょ」・・・実は、ネットの攻撃は無差別に“自動”で仕掛けられるものが大半。たとえば放置しているWordPressの管理画面に、世界中からブルートフォース（総当たり）アタックが日常的に来るのは、実際によくある話。だから「最低限」だけでも、しておかないとだめなんだよね。サーバ委に対する、権限とかが影響して、できることにはもちろん限りもあるけどね。   セキュリティ対策の考え方 専門的な技術的な説明ではなく、なるべくわかりやすく記録しておく。 インターネットにおけるセキュリティ対策は、どこの時点で、何から守るかを明確に定義して、それに粛々と対応してゆくことが大事だと思っている。 何層かにわけた図とかよくあるけど、要に次の３つに分けられると思う。 一番外側　フロントと呼ばれるブラウザで直接アクセスするところ アクセスしたあと、プログラムなどの仕組みが動いているところ 大元のアクセスする基本部分 言い換えるね。 フロント（入口） 　└ サイトを見に来た“誰でも触れる部分” 　　→ ログイン画面、フォームなど 仕組み（中身） 　└ サイトを動かしているプログラム部分 　　→ CMS（WordPress等）、各種プラグイン、APIなど 土台（基盤） 　└ サーバやOS、データベース、ネットワーク設定 じゃ　実践記録を。 フロント（入口） .htaccess というサイトにおいて色々な設定ができるファイル。最近は、rootという権限を持っていないサーバーでも、レンタルサーバーでも設定できるようになってきているね。 # ======================================== # リスト表示させない # ======================================== Options -Indexes # ======================================== # ファイル保護 # ======================================== <Files ".htaccess"> Order Deny,Allow Deny from all </Files> <Files ".htpasswd"> Order Deny,Allow Deny from all </Files> # ======================================== # アップロードファイル保護 # ======================================== # ログ・設定ファイル保護 <Files "*.log"> Order Deny,Allow Deny from all </Files> <Files "*.ini"> Order Deny,Allow Deny from all </Files> <Files "*.conf"> Order Deny,Allow Deny from all </Files> # バックアップファイル保護 <Files "*.bak"> Order Deny,Allow Deny from all </Files> <Files "*.backup"> Order Deny,Allow Deny from all </Files> <Files "*.old"> Order Deny,Allow Deny from all </Files> <Files "*.tmp"> Order Deny,Allow Deny from all </Files> # ======================================== # 著名な攻撃への基礎対策 # ======================================== # SQLインジェクション対策 RewriteCond %{QUERY_STRING} (union|select|insert|delete|update|drop|create|alter|exec|script) [NC] RewriteRule ^(.*)$ - [F,L] # XSS対策 RewriteCond %{QUERY_STRING} (<script|<iframe|<object|<embed|javascript:|vbscript:|onload|onerror) [NC] RewriteRule ^(.*)$ - [F,L] # パストラバーサル対策 RewriteCond %{REQUEST_URI} (\.\.\/|\.\.\\|%2e%2e%2f|%2e%2e\\) [NC] RewriteRule ^(.*)$ - [F,L] # 不正なユーザーエージェント対策 RewriteCond %{HTTP_USER_AGENT} ^$ [OR] RewriteCond %{HTTP_USER_AGENT} (sqlmap|nmap|nikto|w3af|acunetix|nessus|openvas) [NC] RewriteRule ^(.*)$ - [F,L] # ======================================== # セキュリティヘッダー強化 # ======================================== <IfModule mod_headers.c> # XSS Protection Header always set X-XSS-Protection "1; mode=block" # Content Type Options Header always set X-Content-Type-Options "nosniff" # Frame Options Header always set X-Frame-Options "SAMEORIGIN" # Referrer Policy Header always set Referrer-Policy "strict-origin-when-cross-origin" # サーバー情報隠蔽 Header unset Server Header unset X-Powered-By </IfModule> 少し説明、付けておきますね。 リスト表示させない ディレクトリの中身が丸見えだと、地味に危ない。見えなくしておくのが吉。 Options -Indexes ファイル保護 設定とかログとか、大事なファイルは外から見えないようにガード。 <Files ~ "\.(env|git|htpasswd|htaccess|ini|log|sh|bak)$"> Order Deny,Allow Deny from all </Files> アップロードファイル保護 もしもユーザーに変なファイルを上げられても、実行させなければとりあえずセーフ。 <FilesMatch "\.(php|cgi|pl|py|exe|sh)$"> Order Deny,Allow Deny from all </FilesMatch> バックアップファイル保護 消し忘れたバックアップ、意外と多い。ここも一応ブロック。 <FilesMatch "\.(bak|old|save|orig)$"> Order Deny,Allow Deny from all </FilesMatch> SQLインジェクション対策 URLに怪しいSQLキーワードが入ってたら強制シャットアウト。ざっくりだけど結構効く。 RewriteCond %{QUERY_STRING} (union|select|insert|delete|update|drop|create|alter|exec|script) [NC] RewriteRule ^(.*)$ - [F,L] XSS対策などHTTPヘッダー追加 サーバーやブラウザに一声かけておくだけで守れる部分は結構ある。 Header always set X-XSS-Protection "1; mode=block" Header always set X-Content-Type-Options "nosniff" Header always set X-Frame-Options "SAMEORIGIN" Header always set Referrer-Policy "strict-origin-when-cross-origin" Header unset Server Header unset X-Powered-By ほんと、シンプルな基本だけど、ひとまず・・・ Google reCaptcha フォームにはこれだね。いまは Version3(V3)。私はロボットじゃない　とか　バイクのある写真選べ　とかなくなって使いやすくなった。閾値をセットして、アクセスがロボットかどうかを判断してくれる。完全、100%とは言えないだろうけど、最低限、ね。ありがとうございます。 １. API KEy の取得 https://developers.google.com/recaptcha?hl=ja こちらで　まずはキーを取得。サイトキー　と　シークレットキー   ２.フロント側 {サイトkey) には取得したサイトキーをセット。 <script src="https://www.google.com/recaptcha/api.js?render={サイトkey)"></script> <script> grecaptcha.ready(function() { grecaptcha.execute('{サイトkey)', {action: 'submit'}).then(function(token) { var recaptchaResponse = document.getElementById('recaptchaResponse'); recaptchaResponse.value = token; }); }); </script> 送信フォームにこれを追加しておく recaptcha の値を格納するところ。 <input type="hidden" name="recaptcha_response" id="recaptchaResponse">   ３.サーバー側 これは phpサイトでの一例。 $_val は送られてくる Recaptcha の値。$_sid はシークレットキー、ね。 public function ckRecaptcha($_val,$_sid) { $_rt = null; if( (!empty($_val)) ){ $recaptcha_secret = $_sid; $recaptch_url = 'https://www.google.com/recaptcha/api/siteverify'; $recaptcha_params = [ 'secret' => $recaptcha_secret, 'response' => $_val, ]; $recaptcha = json_decode(file_get_contents($recaptch_url . '?' . http_build_query($recaptcha_params))); if(!( (!empty($recaptcha)) &&(!empty($recaptcha->score)) )){ $_rt = false; }else{ if ($recaptcha->score >= 0.6) { $_rt = true; } else { $_rt = false; } } } return $_rt; } こういう関数を用意してチェック。でも実際は、サーバーの様々な理由から簡単に導入できず数日悩むこともあるんだよね・・・まぁ、それに泥臭く対応するのが仕事なんだけど。 今日はここまで。本当はもっと　フロント側やったことあるので、また、ここに追記しておきます。 後日、 仕組み（中身） 土台（基盤） でやったことも公開しておきます。お役に立てれば・・・