その一方で、モバイル端末のスマホサイトの場合、iPhoneユーザーのシェアが多く、この場合はサファリになるため、綺麗に表示される「ヒラギノ角ゴ ProN W3」を使うことができます。
この「Noto」と「ヒラギノ」を天秤にかけた場合、フォントの美しさという点では互角か、もしくはわずかに「ヒラギノ」に軍配が上がると感じています。そのため、あえて転送量が大きくなるWEBフォントの「Noto」をモバイル端末向けに使用する必要性はないと考えており、モバイル端末ではWEBフォントを無効にしています。
大手サイトを閲覧しても、おおむねWEBフォントは使用されていないことが多く、基本的にはメイリオが使用されています。個人サイト等でWEBフォントを使用しているケースも多いですが、それがかえって読みにくくなっているのではないかと感じることもあります。
そのため、個人的にはサイトでWEBフォントを使用する必要はないと感じており、モバイルサイトでは上記の理由でなおさらないと考えてますが、もし使用するなら、PCサイトでのみ表示されるようにするとよいでしょう。
フォント専用のCSSを作成し、 media="screen and (min-width:480px)">などと指定して、PCサイトでのみ読み込む形にすると最適化できると思います。
]]>特にYMYLジャンルではこの傾向が強く、運営者情報や問い合わせフォームなどはもとより、誰がそのコンテンツを作成したのかについて、詳細な情報が求められるようになってきています。
ただ、運営者情報だけでよいのかでいえば、そういうわけでもありません。
「運営者情報」のほか、「問い合わせフォーム」や「利用規約」、「プライバシーポリシー」、「サイトの目的」、あるいは法人の場合は会社の沿革など、可能な限り充実したコンテンツを作成する必要があります。
加えて、コンテンツ作成者についての詳細な情報も必要です。
そのコンテンツを誰が作成したのかについて、SNSでのプロフィールなどもあれば、公開しておくとよいでしょう。
ここで一つの疑問が出てきますが、運営者情報がSEO対策になるのであれば、医師や士業の方へ監修料として謝礼を払い、名前を借りてサイトを運営すれば、検索でヒットしやすくなるのではないかという点です。
権威性をお金で購入してサイト運営で収入を得る、今後はそんな時代がやってくるのではないかと感じています。
]]>本来書くはずだった内容をAとしますと、キーワード検索回数のチェックにより、Bという内容に仕上がってしまい、本来書きたかった内容からズレて不自然な内容に仕上がってしまう弊害があります。
また、他の人も同じ方法をとることにより、検索結果では同じようなタイトルが並んでしまうことになり、オリジナリティーが消失してしまう弊害があります。
特に、ライターに記事を依頼して作成する場合はこのようなパターンが多く、最近のインターネットの風潮にぼくは危機感をいだいております。
全員が全員、検索回数の多い既存のキーワードを元にコンテンツを作成した場合、新しいキーワードもコンテンツも世の中には生まれて来ません。結果として、ネット上には似たようなコンテンツばかりが生まれてしまい、多様性が失われ、社会の進歩が停滞してしまうことになります。
ウェブマスターたるもの、常にコンテンツのフロンティア・スピリットを持ち続け、新しいキーワードを開拓する必要があります。
しかしながら、現実問題でいいますと、このような方法はアクセスアップには全くつながりません。それもそのはず、誰も知らない新しいキーワードは誰も検索することがなく、アクセスの流入につながらないからです。
悲しいかな、誰にも検索されないコンテンツというのは、この世に存在しないも同じなのです。
以上のような理由にて、フロンティア・スピリットを持つべきだとは思いますが、機械的に検索回数の多いキーワードに寄せてコンテンツの作成を行った方が、アクセスアップの面では有利といえるでしょう。
]]>MFIにより、モバイルサイトに最適化しておくのは当然ではありますが、最低限の最適化さえできていれば、SEO効果への影響はあまり大きくはないと考えています。加えて、コアウェブバイタルやAMPなども話題になってはいますが、AMPなどに対応してもSEO対策上、特に大きな影響はないはずです。
それよりも、やはりコンテンツの質と被リンク数がSEO対策への影響が大きい要素であるといえます。
特に、被リンクについてですが、検索結果で実際に表示されているサイトであり、リアルなアクセスがあり、被リンク数やドメインの運営年数が長いサイトからのリンクを受けることが検索順位上昇への貢献度が高いです。
アクセスのないサイトについては、存在しないも同じであるため、そのようなサイトからの被リンクはそれほど効果があるものではありません。
以前までは、単純に被リンク数が多いとか、ページボリュームが多いとか、あるいは更新頻度が高いなど、それらの要素が重要でした。
けれども、現在は検索結果での露出度が高いか、もしくは実際にアクセス数が発生しているのかを重要な要素として考えるべきかと思います。
]]>なかでも特に、「個人関連情報の第三者提供の制限等」に関する項目がポイントになると思いますが、まずは「個人情報」と「個人関連情報」の違いを確認しておくことをおすすめします。
「個人情報」については氏名や電話番号、メールアドレス、住所や生年月日などが該当します。
一方、「個人関連情報」については「関連」の文字が付いていますが、IPアドレスやクッキーなど、それ自体では氏名などは分からないものの、アクセス解析などのデータに関連した情報になります。
これまで、サイトのIPアドレスなどのアクセスログについては、公的機関が介入しない限り、それ自体では個人を特定することは困難でしたが、外部に提供することにより判明が可能となってしまう事例が出てきました。
例えば、リクナビの内定辞退率を予測するサービスが問題となりましたが、サイト内での行動パターンなどの情報から、内定を辞退する率を割り出して企業に販売するといった事例がありました。
サイト内での行動履歴などのデータについては、個人関連情報になり、それ自体では個人情報にはなりませんが、提供先の企業ではそのユーザーについての個人情報を保有している場合、それを紐づけすることで間接的には誰がどのような行動履歴をとり、過去のパターンから内定辞退率はどのくらいかということが判明してしまいます。
このようなケースがあるため、今回の改正個人情報保護法では、提供元では個人データに該当しないとしても、提供先で個人データに該当する場合には、本人の同意が得られていることの確認が義務付けられました。
そのため、この点でサイト内のプライバシーポリシーの改訂が必要になってくるものと思われます。
]]>ChatGptは無料でも利用できますが、当サイト運営者は有料版で使用しています。
教材で学習する方法と比較しますと、AIで学習する方が学習スピードが飛躍的に向上すると感じています。
その理由としまして、プログラミングコードについて、1行1行質問しながら学習することにより、疑問点を全て解消しながら習得できるという違いがあります。
これが教材の場合ですと、疑問点の答えが掲載されている箇所を1つ1つ探しながら解消していく必要があるため、非常に時間がかかります。その点、ChatGPTの場合ですと、AIに聞けばその場で答えがすぐに出てくるため、習得にかかるスピードが飛躍的に短縮されるメリットがあるわけです。
その都度、分かるまでしつこく質問するということは、対面のプログラミングスクールなどでは憚りがありますし、機械のAIだからこそ、遠慮なく質問することができます。
加えて、おそらくは答えの精度や速度も、プログラミングスクールの先生よりも上ではないでしょうか。
この点が非常にメリットがあり、今後はおそらく、プログラミングスクールは次々に廃業に追いやられるのではないかと考えています。
月20ドル、または無料で、おそらくは数十万円分の価値を享受できるものと感じておりますが、これを利用しない手はないです。
ChatGPTの登場により、おそらく、今後の半年間で私たちの社会が劇的に変化していくのではないか、そう考えています。
]]>サイトにJavaScriptを設置してクリック数をカウントすることはできるものの、ブラウザを更新したらゼロに戻ってしまうため、他のユーザーも合わせた累計でのいいね!数をカウントすることはできません。
そのため、ブラウザなどのクライアント側の対応だけでは不十分であり、サーバーサイドのデータベースでもクリック数を保持して管理する必要があります。この場合、一般的には、クライアントサイドからサーバーサイドにリクエストを送信し、クリック数を更新して取得するような仕組みを実装することが必要になります。
例えば、JavaScriptでいいね!のクリックイベントを検出した後、AjaxやAPIなどを使用してサーバーサイドにリクエストを送信し、サーバーサイドでのデータベースにアクセスしてカウントを更新・取得する形になります。
その後、サーバーサイドからクライアントサイド側に返されたデータをもとに、サイト上のいいね!のカウントの表示を更新するという仕組みになります。
このサーバーサイド側で処理する方法については、具体的にはPHPやPythonなどのプログラミング言語で実装することができますが、その際にはサーバーサイドとクライアントサイドが連携して動作するように、適切なコードを実装する必要があります。
これは、いいね!ボタンのほか、記事のクリック回数をカウントすることによって、人気記事のランキング表示の実装なども可能になります。
サーバーサイド側のプログラムをサイト上に実装することにより、よりインタラクティブで複雑な機能の実装が可能となります。
]]>しかしながら、Chromeのデベロッパーツールなどで確認しましても、サイトの高層化にはそれほど大きな影響はないと感じています。
この原因についてですが、パフォーマンスを確認してみますと、そもそもサーバーが画像を配信する秒数は非常に短く、複数の画像を同時に配信してくるため、数十KB程度の画像で数枚程度なら、遅延読み込みで枚数を減らしてもそれほど大きな影響はないものと思います。
サイトの高速化について、それよりも大きな影響があるのは、レンダリングの処理計算にかかる時間で差が出ることが多いです。
レンダリングをする際、レイアウトの複雑な計算を何度もしなおすことで時間がかかり、高速化のボトルネックとなっていることが多いと感じています。
ただし、ブラウザが実行するレンダリング計算の中身というか、プロセスが不明なため、この点を改善するにはかなり時間がかかりそうと考えています。
ただし、ページ内で無数の画像やWebフォントを使用している際には、ファーストビュー以外の画像の読み込みを遅延させ、スクロールして実際に表示される時になってから表示させるようにすれば、多少の高速化効果は見込めるものと思います。
これを実行するには、JavaScriptでの実装が必要になりますが、いわゆるIntersection Observerという技術を使うことで実装することができます。
イメージでいえば、あえてファーストビュー以外の<img>タグのsrcを崩すことにより、画像と認識されなくなるため、HTMLを読み込んだ時点では画像をダウンロードしなくなります。
<img>タグのままでしたら、HTMLファイルを読み込んだ時点でダウンロードされてしまうため、遅延することはできないため、<img>タグをそのままでな機能しないようにする必要があります。
けれども、ユーザーがスクロールをして、画像コンテンツの箇所に差し掛かった際に、<img>タグの箇所に投入するという仕組みです。
Webフォントについては、単なる遅延読み込みのため、ファーストビューが表示された後、実際にWebフォントが反映されますが、画像とWebフォントの遅延読み込みでは、Intersection Observerの仕組みを使うか使わないかでの違いがあります。
WebフォントでもIntersection Observerも使うことは可能ですが、特にメリットはないと感じています。
ただし、このような画像の遅延読み込みをしましても、そもそも数枚程度の画像の読み込みでしたら、それほど時間はかからないため、遅延してもしなくてもあまり大きな違いはないというのがぼくの印象です。
]]>今までは、フロントエンドのHTML、CSSぐらいは習得していましたが、これらはプログラミング言語というよりも、マークアップ言語のため、それほど難易度が高いわけではありません。
それが、この3ヶ月でHTML、CSSに加え、バックエンドのJavaScript、PHP、SQL、Pythonと、過去5年分ぐらいのスキルアップが実現したと感じています。その過程で、MySQLなどのデータベースに加え、Gitなども少しはかじっています。
もちろん、深く習得したわけではなく、読めて簡単なものでしたら書けるぐらいです。
HTMLやCSSについては、スラスラ読めて書けるぐらいには慣れ親しんでいますが、JavaScriptやPHP、SQLについては、まだぎこちない感覚があり、すんなり頭に入ってくるわけではありません。ただ、入門書レベルの書籍でしたら、内容がスラスラ入ってくる状態です。
この分ですと、年内にはよく分からないJava、Perl、C言語などもある程度は習得できそうな気もしており、ウェブ開発におけるLAMP(Linux、Apache、MySQL、PHP)あたりは、ものに出来そうな予感がしています。
フロントエンドに加え、バックエンドのプログラミング言語をかじったことにより、ウェブ開発の全貌がおぼろげながらも理解できてきたように感じます。
このChatGPTによる習得スピードが速い理由については、疑問点をその場で何度も質問しながら、ステップバイステップで習得できるからだろうと感じています。
インタラクティブなやり取りにより、疑問点を潰しながら進めますし、初歩的な質問についても、AIなら気兼ねなく、分かるまで24時間何度でも質問できます。
それに加えて、回答速度も一瞬で、口頭での説明ではなく、文章での説明のため、情報の吸収量が極めて効率的です。また、かなり正確な情報を提供してくれます。
さらに、よく間違えるという点も、プラスに働いているものと感じています。
ChatGPTから提供されたコードについては、大まかには合っていますが、ところどころ間違っており、実際には動かないケースが多いです。
そのため、1行づつ確認しながら、動かない箇所を調べていくわけですが、この確認をする過程にて、ああでもないこうでもないと繰り返しているうちに、この行は何度も確認したし、問題はここではないという状態になります。
この間違い探しをする上で、コードの意味やシンタックスを正確に確認しないといけませんし、結果的に、この確認作業がプログラミング習得にとって、極めて効率的に作用するものと感じます。
もし、そのままうごくコードばかりをChatGPTに提供されるとしたら、コピペして終わりのため、何らスキルアップには役立たないことでしょう。
これからプログラミングを習得しようとしている方は、実際にコードを書いてもらいつつ、そのコードの間違いを探すようなスタンスで取り組むと、習得スピードが飛躍的に向上するものと思います。
]]>AMPの最大のメリットは、モバイル環境での高速化にありますが、そもそも静的なWebサイトを運営している場合、WordPressのような動的なウェブサイトよりも高速で表示される傾向があります。
それでも、AMPページの方が高速で表示されるのは事実ですが、コンマ数秒程度の違いのため、そのメリットとデメリットを秤にかけた場合、自サイトの場合は終了した方がよいと判断しました。
AMPのデメリットでいえば、やはりJavaScriptが大幅に制限される点があると思います。ツールサイトのような、JavaScript主体で運営しているサイトの場合は対応が難しいでしょうし、広告についてもJavaScriptを使用している場合には制限されることになります。
さらに、正規ページとAMPページにて、2ページ分の対応が必要になるため、時間などの管理コストが増大する傾向にあります。
この点が非常に手間がかかると感じており、1ページ更新するのにも、1.3倍程度の手間がかかると感じました。
それでも、SEO対策上、AMP対応の有無がランキング要素になるのでしたら、また別ですが、直接的な影響はなく、高速化することによる間接的な影響しかないものと感じています。
また、カルーセルの表示など、AMPによる特典のようなものは存在するものの、単純に管理コストを下げ、更新頻度を高めた方が全体としてのパフォーマンスは向上する気もしています。
そのような理由にて、迷った末にAMPへの対応は終了することにしたのですが、出来るだけシンプルな形で運営していく予定でいます。
]]>一方で、HTMLやCSSは有名ではあるものの、単にプログラミング言語とはいえない部分があり、マークアップ言語やCSSとも呼ばれています。やはり、条件分離や定義をしての操作などがない場合、プログラミング言語とはいえないのかもしれません。
そのような、プログラミング言語とはいえないものの、習得するためのコストが低く、サイト運営に役立つコスパ高い言語の一覧をご紹介します。(※HTMLとCSSは除く。)
■言語的なものの一覧
1、SQL
2、Apacheの設定構文
3、Curlコマンド
4、Jquery
5、WordPress独自タグ
6、xml
7、JSON
8、CGI
9、Winコマンドブロンプト
10、logファイル
11、CSVファイル
12、正規表現
1.SQLについて
SQLはデータベースを操作する言語ですが、SELECT、UPDATEなどの構文でデータベースを操作します。ただし、Webサイト上から操作するには、PHPなどのプログラミング言語との連携が必要になります。PHPファイルに記載することが多いと思います。
WordPressを使用している場合にも、サイトの移転などで使用することがあるかもしれません。
2.Apache
単にApacheといった場合、通常ですとApache HTTPサーバーのことを指すことが多いです。サイトの.htaccessなどを設定する際、RewriteEngine Onなどと記載することが多いですが、このサーバーを設定する際、Apacheの構文や指令のディレクティブを使用することになります。
ただし、これらはプログラミング言語ではなく、設定するための指示言語です。常時SSLや301リダイレクト設定をする際には、こちらを使用するとよいでしょう。
3.Curlコマンド
当サイト運営者の場合、こちらはWindowsのコマンドブロンプトから使用することが多いですが、HTTPリスポンスを確認する際によく利用します。
4.Jquery
Jqueryについては、JavaScriptのライブラリーのため、実際のところはJavaScriptといえます。一方で、ライブラリを使わず、生のJavaScriptについては、バニラJSと呼ぶことがあります。当サイト運営者の場合、細かい点まで管理したいため、バニラJSで使用することが多いです。
同様に、JavaScript関連ではReactがあり、React.jsと呼ばれていますが、こちらについてはFacebookが開発したものになります。
5~11
そのほか、独特な言語的なものがありますが、サイトマップを作成でxmlを使用することが多いですし、エラーログを出力した際には、ログファイルを確認するとエラーメッセージなどの独特な書き方がされています。
コマンドブロンプトについては、直接的にはサイト運営で使用することはありませんが、当サイト運営者はwois情報の確認やWebフォントのサブセットで使用することが多いです。
12.正規表現
正規表現自体はプログラミング言語ではありませんが、JavaScript、Python、Java、Perl、Rubyなど、多くのプログラミング言語で正規表現をサポートしています。
JavaScriptにて使用することが多いかもしれません。
そのほか、サイト作成でCMSを使用する際には、WordPressやMovable Typeなどで独自の構文を使用することがあります。
上記については、プログラミング言語とはいえませんが、比較的、習得するには簡単たなめ、短時間で効率よく習得できると思います。コスパ高い言語になるので、覚えておくとよいでしょう。
]]>その点、ホームページ作成ソフトのDreamweaverなどを使用すれば、パソコン上で直感的に作業できるため、効率的ではありますが、条件を指定した上での分岐処理など、より複雑なプログラミング的な操作はDreamweaverでも困難な傾向があります。
このような場合、人気プログラミング言語のPythonを使用すれば、パソコン上のホームページファイルに対して様々な操作ができて便利です。
特に、PythonのライブラリにBeautifulSoupやosがありますが、パソコン上のHTMLファイルを読み取り、解析し、修正し、再度保存するといった一連の操作を自動化することが可能となります。
Pythonといえば、ウェブスクレイピング的な操作をするプログラミング言語と思われていますが、そのスクレイピングは、Web上だけではなく、パソコン上のファイルでも可能なのです。
このPythonには、以下のようなライブラリやモジュールがあり、ホームページの作成と親和性が高いです。
■re
正規表現を扱うためのモジュールです。正規表現で特定のパターンに一致する文字列を検索したり、置換したりできます
■os
ファイルやディレクトリの操作、パスの操作、プロセス管理など、osの名前どおり、オペレーティングシステムレベルのタスクを実行するためのモジュールです。
■shutil
ファイルやディレクトリのコピー、あるいは移動や削除などのファイル操作ができます。
■glob
ディレクトリのワイルドカード検索を行うためのモジュールです。
■codecs
文字コードを変換する際に使用すると便利です。このモジュールを使うことで特定のエンコーディングでファイルを読み書きしたり、文字コードを変換したりできます。
■BeautifulSoup
HTMLやXMLのパースや操作、スクレイピングを行うためのライブラリです。HTMLファイルの中身を操作する際に使用すると便利です。
これらのライブラリを使いこなすことができれば、HTMLタグを手打ちしてホームページを作成しているユーザーにとって、強力なツールとなり得ます。
JavaScriptと比較しても、Pythonは初心者の方でも比較的、わかりやすいプログラミング言語となっているため、HTMLやCSSの次は、Pythonの習得に取り組んでみてはいかがかと思います。
]]>しかしながら、そこから先、.exe化してスタンドアロンの形にしようと思ったのですが、モジュールまでを組み込むのは難しく、最終的には断念する結果になっています。
この.pyファイルと.exeの違いですが、.pyは必要なPythonのプログラムがパソコン上に入っている必要がありますが、.exeファイルにはPython自体も組み込むことにより、単独で機能することになります。
そのため、ファイルをダウンロードしさえすれば、必要なプログラムは全て用意されている状態のため、単独で機能するソフトウェアになる利点があります。
けれども、Pythonの場合、必要なモジュールが複数あり、それはまた別にインストールする必要があるため、必要なソフトウェアを一括でそろえるのが困難であるとの結論に達しました。
あえなく、.pyの形式で使用しているのですが、それでも自分で使用する分には、既にある.pyファイルも.exeファイルも使用感は特に変わりはないため、そのまま使用しています。
この.exeファイルでスタンドアロン化するメリットは、人に配布するとか、あるいはダウンロード販売をする際には必要かもしれませんが、自分でそのソフトウェアを使用する分には、必要な要件は既にそろっているため、あえてパッケージ化する必要はないかもしれません。
それでももし、あえてスタンドアロン化する場合には、動作条件として必要なプログラムやモジュールを指定するなど、事前に説明した上で配布することをおすすめします。
]]>Forbidden
You don't have permission to access this resource.
これは通常、.htaccessにて、サイト運営者によってアクセスが拒否された際に表示されることが多いです。
けれども、先日、管理サイトの1つにて、いつもとは違うForbiddenエラーが表示されていました。
Forbidden
You don't have permission to access this resource.Server unable to read htaccess file, denying access to be safe
おかしいな?と思いつつ、.htaccessを確認してみたのですが、deny fromなどでアクセスを拒否するような設定は何もしていません。
そこで改めてエラー内容を読んでみますと、「Server unable to read htaccess file」と書いてあり、これはつまり、サーバーが.htaccessファイルの中身を読み取ることができないため、安全のためにアクセスが拒否された意味になります。します。
つまり、.htaccessに書かれている内容で拒否されているというわけではありません。
一方で、パーミッションで.htaccessへの読み込みを拒否しているわけでもなかったため、これはサイト運営者側ではなく、ウェブサーバー側でアクセスを拒否していることを意味します。
同じサーバーに設置している他のサイトも確認してみたところ、同じように上記のForbiddenが表示されていました。
そこで、運営会社に問い合わせようと思ったのですが、メールアカウントを確認してみますと、「サイトが改竄されて踏み台にされてるので、サーバーアカウントを凍結しました」との内容のメールが来ていたようです。
つまり、CMSが不正にアクセスされて改竄されてしまい、サーバー内に設置している全てのサイトが書き換えられる結果になっていました。
よく見てみますと、おかしなコードが多数挿入されており、ファイル自体が削除できなくなったりもしており、複数の侵入口が作られる結果になってしまいました。
一応、データベースやHTMLファイル、メール、アクセスログなど、全てクリーンな状態にはしましたが、削除できなくなったファイルなどもあり、もはやそのサーバーごとは移転するしかありません。目視で不正なコードを一つ一つ削除していったとしても、また再度、改竄される結果になるはずです。
結論としては、上記のForbiddenエラーが発生した場合、そのサーバーはもう諦めざるを得ないという結果になります。
そのため、ファイルをクリーンにしてから移転することをおすすめします。
]]>なかには、サイトが改竄されたきり、放置状態になっていたものもあり、共有サーバー内のサイトが全滅していたケースもありました。あるいは、SSLの更新が失効し、危険なサイトと表示されているケースもありました。
それに気づかず、毎年、ドメイン代とサーバー費用を更新してきたわけですから、おそらく、膨大な費用を無駄に払っていたことになります。
一方で、大量にドメインとサーバーを解約したとしても、アクセス数にはほとんど影響が出ていません。むしろ、失敗していたSSLを復旧したり、改竄されていたサイトをクリーンアップすることにより、アクセスアップにつながっているケースも出てきています。
コストを削減して規模を縮小することにより、てっきり収益は減少すると考えていたのですが、逆に増える結果になりました。
結果的に気付いたことではありますが、ドメインやサーバーを必要なものだけに絞り、少数精鋭で管理することにより、ある意味ではプラスの影響が出てくるのではないかと感じています。
自分の場合、法人を精算することにしたため、強制的にサーバーとドメインを解約することになったわけですが、これを5年前、10年前にやっておけば、ずいぶんと違っていたのかもしれません。
管理しきれないサイトを保有するのは、デメリットの方が大きいものと思います。思い切って、使用していないドメインやサーバーは解約すると、プラスのメリットが出てくるかもしれません。
]]>