2019年4月26日金曜日

Googleが掲げる10の事実

Googleが掲げる10の事実
  1. ユーザーに焦点を絞れば、他のものはみな後からついてくる。
  2. 1つのことをとことん極めてうまくやるのが一番。
  3. 遅いより速いほうがいい。
  4. ウェブ上の民主主義は機能します。
  5. 情報を探したくなるのはパソコンの前にいるときだけではない。
  6. 悪事を働かなくてもお金は稼げる。
  7. 世の中にはまだまだ情報があふれている。
  8. 情報のニーズはすべての国境を越える。
  9. スーツがなくても真剣に仕事はできる。
  10. 「すばらしい」では足りない。
引用元: http://www.google.com/intl/ja_JP/about/company/philosophy/
投稿者 時刻: 0 件のコメント :

2018年12月11日火曜日

改善できる項目「使用していない CSS の遅延読み込み」


「使用していないルールをスタイルシートから削除して、データ通信量を減らしてください。」となっているこの項目に関しては、読み込みのタイミングを変更するなど方法はありますが、今回は「未使用のCSSを整理する事」を検討しました。

未使用のCSSを整理する場合にチェックツールはいくつかありますが、Google Chromeでも調査可能です。
1Google Chromeのデベロッパーツールを起動
2[Console]を表示し、画面を閉じる×アイコンの下の [⋮]→[More tools]→[Coverage]

3reloadアイコンをクリック

すると、デベロッパーツールの下部に、読み込んでいるCSSなどのファイルが表示されます。
該当のファイルをクリックすると、緑のバーと赤色でセレクタが表示されますが
赤色（未使用のセレクタ）のセレクタを確認、整理する事ができます。
ここで1点注意が必要です。レスポンシブデザイン用のメディアクエリの部分も赤色で表示されます。削除する前は、事前にバックアップを残しておき、注意し作業を実行しましょう。
投稿者 時刻: 0 件のコメント :

2018年8月26日日曜日

Googleがスマホ専用の検索結果の導入を予定


Googleがスマホ専用の検索結果の導入を予定しているので、

将来的にはスマホ独自のSEO対策が誕生するかも知れませんね。

その時にそなえ、スマホ独自のコンテンツでスマホの特徴を生かした

モバイルフレンドリーなサイトを作りましょう。
投稿者 時刻: 0 件のコメント :

2018年7月18日水曜日

Let's EncryptのCertificate Transparency対応

Let's EncryptのCertificate Transparency対応

延期に延期を重ねていた、Let's Encryptへの証明書タイムスタンプ署名：Signed Certificate Timestamp（SCT）の埋め込みですが、2018年3月29日から開始いたしました。
これによれり、ブラウザなどで、
証明書の透過性(Certificate Transparency)を確認できるようになります。
公式のcertbotよりもacme.shの方が、対応機種が広く、
開発言語に依存する部分も少ないため、ここでもacme.shを使った再取得の例を示します。
acme.shの詳しい使い方は、
>>acme.shを使った国際化ドメイン名の証明書の取得例
をご覧ください。
[2018年6月5日追記］　
Appleが、2018年10月15日以降、TLS証明書のCertificate Transparencyを
強制するとの声明を発表しました。

Embed SCT付き証明書の取得

取得と行っても、2018年3月29日以降、Let's Encryptから取得する証明書は、Embed SCTがもれなく、付いてきます。
2018年以前に取得居ている方は、再取得すればOK。
acme.shの場合、以下のような感じでしょうか。
# cd ~/.acme.sh 
# ./acme.sh --renew --force -d www.example.com
楕円曲線の証明書の再取得は以下のようになります。
# cd ~/.acme.sh 
# ./acme.sh --renew --force -d www.example.com --ecc
続いて、実際にSCTが埋め込まれているか、OpenSSLから確認してみ

コマンドラインからEmbed SCTを確認する。

コマンドラインからOpenSSLを使ってEmbed SCTを確認します。
（※　OpenSSL 1.0.1以前のバージョンは、サポート期限が終了しています。
OpenSSL 1.0.2以降を利用してください。）
以下、acme.shで取得した、ECDSA(楕円曲線)を使った証明書のサンプルです。
# /usr/local/bin/openssl x509 -in ~/.acme.sh/www.example.com_ecc/www.example.com.cer -text
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            (･･･省略･･･)
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
        Validity
            Not Before: Mar 29 XX:XX:XX 2018 GMT
            Not After : Jun 27 XX:XX:XX 2018 GMT
        Subject: CN = www.example.com
        Subject Public Key Info:
            Public Key Algorithm: id-ecPublicKey
                Public-Key: (256 bit)
                pub:
                    (･･･省略･･･)
                ASN1 OID: prime256v1
                NIST CURVE: P-256
        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature
            X509v3 Extended Key Usage:
                TLS Web Server Authentication, TLS Web Client Authentication
            X509v3 Basic Constraints: critical
                CA:FALSE
            X509v3 Subject Key Identifier:
                (･･･省略･･･)
            X509v3 Authority Key Identifier:
                keyid:(･･･省略･･･)

            Authority Information Access:
                OCSP - URI:http://ocsp.int-x3.letsencrypt.org
                CA Issuers - URI:http://cert.int-x3.letsencrypt.org/

            X509v3 Subject Alternative Name:
                DNS:www.example.com
            X509v3 Certificate Policies:
                Policy: 2.23.140.1.2.1
                Policy: 1.3.6.1.4.1.44947.1.1.1
                  CPS: http://cps.letsencrypt.org
                  User Notice:
                    Explicit Text: This Certificate may only be relied upon by Relying Parties and only in accordance with the Certificate Policy found at https://letsencrypt.org/repository/

            CT Precertificate SCTs:
                Signed Certificate Timestamp:
                    Version   : v1 (0x0)
                    Log ID    : DB:74:AF:EE:CB:29:EC:B1:FE:CA:3E:71:6D:2C:E5:B9:
                                AA:BB:36:F7:84:71:83:C7:5D:9D:4F:37:B6:1F:BF:64
                    Timestamp : Mar 29 23:22:39.417 2018 GMT
                    Extensions: none
                    Signature : ecdsa-with-SHA256
                                30:44:02:20:2B:F2:E4:D8:F4:83:17:33:F4:79:2B:B3:
                                5F:87:C0:AF:BE:6D:43:98:A2:0C:0B:72:BC:CE:64:C2:
                                56:F4:2F:2C:02:20:5C:D3:A0:92:7C:B2:A5:FA:E7:2F:
                                39:61:27:23:75:82:AF:1F:C2:53:DA:0E:04:CB:3B:12:
                                4D:94:4D:BA:09:26
                Signed Certificate Timestamp:
                    Version   : v1 (0x0)
                    Log ID    : 29:3C:51:96:54:C8:39:65:BA:AA:50:FC:58:07:D4:B7:
                                6F:BF:58:7A:29:72:DC:A4:C3:0C:F4:E5:45:47:F4:78
                    Timestamp : Mar 29 23:22:39.451 2018 GMT
                    Extensions: none
                    Signature : ecdsa-with-SHA256
                                30:45:02:20:34:ED:FA:D8:9F:54:E5:9A:3E:ED:7B:62:
                                57:71:85:71:6F:FC:AC:D0:7D:25:BC:43:6B:8D:CF:BA:
                                F4:28:28:B7:02:21:00:CE:57:28:AD:A9:49:1A:2E:81:
                                76:95:7C:16:35:F1:70:D0:00:E0:F6:E9:8E:70:70:8C:
                                09:3B:96:B2:F0:24:4F
    Signature Algorithm: sha256WithRSAEncryption
 (･･･省略･･･)
-----BEGIN CERTIFICATE-----
 (･･･省略･･･)
-----END CERTIFICATE-----
緑の部分ようにCT Precertificate SCTs:や
Signed Certificate Timestamp:が追加されていれば問題ありません。
Cloudflare 'Nimbus2018' Logと、Google 'Icarus' logを利用しているようです。
（一つ目の、Log ID : DB:74から始まる方がCloudflare 'Nimbus2018' Logで、二つ目のLog ID : 29:3Cから始まる方が、Google 'Icarus' logです。）
ちなみに、RSAのサーバ証明書を取得しても、SCTの署名は、ECDSAで行われるようです。

apachctl -tで、設定ファイルの間違いが無いことを確認の上、下記のように
# /usr/local/apache2/bin/apachctl -t
Syntax OK
# /usr/local/apache2/bin/apachctl stop
# /usr/local/apache2/bin/apachctl start
再起動します。

chromeからEmbed SCTを確認する。

さきほど、OpenSSLのコマンドラインから確認した内容はChromeからも確認できます。
リスタートしたサーバにChromeでアクセスして　、「ディベロッパーツール」を表示（WindowsだとCTRL+SHIFT+IのショートカットキーでもOK）して、「Security」タブを表示します。
そして、左側のMain Originにある、Let's Encryptから証明書を取得したサイトのドメイン名をクリックすると、右側にCertificate Transparencyが表示されればOKです。
また、QualysのSSL LabsのServer Testを使って調べると以下のような出力になります。

これで、証明書の透過性を含んだ検証ができていることが判ります。
NEXT >> HTTP/2の動作確認
投稿者 時刻: 0 件のコメント :

2018年7月16日月曜日

SSL気になる記事を発見？

ＳＳＬについて気になる記事を発見しましたので

ご興味がある方は下記のＵＲＬをクリックしてみてください。

https://blog.apar.jp/web/8281/#_SSL
投稿者 時刻: 0 件のコメント :

2018年7月5日木曜日

さくらVPS仮想サーバーで、サブドメインを利用しWordPress公開方法。

環境：CentOS 5.5
WEBサーバー：apache
ドメインはさくらのドメインサービスを使用
下記例は
サブドメイン　subdomain.earthyworld.com
公開ディレクトリ　/home/*/public_html
とします。

目次
  1. ドメイン設定
  2. httpd.confの設定
  3. WordPressの設定

１．ドメイン設定

■さくらインターネットのドメイン設定に行く。
https://secure.sakura.ad.jp/menu/domain/
■サブドメインを作るドメインを指定の「ゾーン設定」をクリック
domain.jpg
■画面左側の「変更」をクリック

■エントリの追加と変更の画面が表示されます。

エントリ名: subdomain
種別: 別名（CNAME）
値：@
に設定し「新規登録」をクリックします。
■「情報が変更されましたが、左の「データ送信」をクリックされるまで、反映されません」という
表示がでるので、左のデータ送信をクリックします。

■送信するとトップ画面にもどり
エントリ名：subdomain
タイプ　:CNAME
データ @
が追加されます。

２．httpd.confの設定

■サーバーにログインします。
おそらくroot もしくは専用のユーザーになっているので、ファイル操作できるユーザーにsuします。
[plain]
sudo su -
[/plain]
httpd.confを設定します。
[plain]
vi /etc/httpd/conf/httpd.conf
[/plain]
975行目あたりに
[plain]
<VirtualHost *:80>
ServerName earthyworld.com
DocumentRoot 公開ディレクトリ
ServerAlias www.earthyworld.com
</VirtualHost>
[/plain]
という記述があるのでその下に
[plain]
<VirtualHost :80>
ServerName subdomain.earthyworld.com
DocumentRoot /home//public_html
&lt;Directory /home/*/public_html/&gt;
 AllowOverride All
 Options FollowSymLinks
 Order allow,deny
  Allow from all
   &lt;/Directory&gt;
</VirtualHost>
[/plain]
を記述します。
CentOSのvi で行数を見るときは コマンドモードで「setnumber[enter]」と打ちます。
■Apacheを再起動します。
[plain]
/etc/rc.d/init.d/httpd restart
httpd を停止中: [ OK ]
httpd を起動中: [ OK ]
[/plain]
起動中　[OK]がでれば完了。

３．Wordpressの設定

ここでは
データベース:sub_wp
すべての権限を持つユーザー:sub_wp
ユーザーパスワード:wordpress
をつくる
■mysql に専用のユーザー、データベースをつくる
mysql にログイン
[plain]
mysql -u root -p
[/plain]
データベースをつくる
[plain]
createdatabase sub_wp;
[/plain]
データベースを選択
[plain]
use sub_wp;
[/plain]
ユーザーをつくる
[plain]
grant all privileges on sub_wp.* to sub_wp@localhost identified by 'wordpress';
[/plain]
ユーザーを反映
[plain]
flush privileges;
[/plain]
WordPressのフォルダを
/home/*/public_htmlにアップ
wp-config.phpの
[plain]
//データベースの名前
define('DB_NAME', 'sub_wp');
//データベースの名前
define('DB_USER', 'sub_wp');
//データベースのユーザーパスワード
define('DB_PASSWORD', 'wordpress');
[/plain]
に書き換える
■アップがおわったらsubdomain.earthyworld.comにアクセスする
WordPressの設定画面が表示されたら画面にしたがってインストールする
投稿者 時刻: 0 件のコメント :

2018年7月3日火曜日

よくわかる ! 受信トレイ無料修復ツール

今、このような悩みはありませんか？


Outlookを使用していると、さまざまな原因でメールデータ―などを


格納しているデータ―ファイルの一部に不整合や破損が生じてしまい


以下のような現象が発生することがあります。


〇 起動できない 〇 送受信できない 〇 メールの削除ができない


もし、上記のような現象が起きていたら

https://www.smile-kyuubin.jp/blog/Outlook%20Navi.pdf

をお読みになり無料で修復しませんか？



投稿者 時刻: 0 件のコメント :

2018年5月10日木曜日

TLS 1.1 および TLS 1.2 の有効化

https://help.salesforce.com/articleView?id=Enabling-TLS-1-1-and-TLS-1-2-in-Internet-Explorer&siteLang=ja&type=1


ATLS1.2設定対応可能ブラウザバージョン一覧


 ブラウザ
バージョン		 TLS 接続可否
PC Windows Internet
Explorer		 11 1.1、1.2 ○
10 1.0、1.1、1.2
9
8
Firefox 24 以上 1.1、1.2 ○
Google Chrome 30 以上 1.1、1.2 ○
Mac Safari 7 以上 1.1、1.2 ○
スマートフォン Android Android 4.4 以上 1.1、1.2 ○
iOS Safari 5 以上 1.1、1.2 ○

BTLS1.2設定対応不可ブラウザバージョン一覧


 ブラウザ
バージョン		 TLS 接続可否
PC Windows Internet
Explorer		 7 以下 1.0 ×
Firefox 23 以下 1.0 ×
Google Chrome 29 以下 1.0 ×
Mac Safari 6 以下 1.0 ×
スマートフォン Android Android 4.3 以下 1.0 ×
iOS Safari 4 以下 1.0 ×
モバイル docomo iモード 1.0 ×
au Ezweb 1.0 ×
Softbank Yahoo!ケータイ 1.0 ×
  • ※ 上記でAのプラウザのバージョンに当てはまる「○」の方で、
  • TLSが1.2以下だった場合は、下記手順でTLS1.2に設定をお願い致します。
  • ※ 上記でBのプラウザのバージョンに当てはまる「×」の方は、2018年3月中旬以降、
  • 順次当社WEBサイトの接続ができなくなる可能性がございます。
投稿者 時刻: 0 件のコメント :

2018年4月27日金曜日

モバイルサイトの速度をテストしましょう。


あなたのモバイルホームページの速度は大丈夫ですか？

多くのサイトで、

訪問者の半数がページの読み込み中に離脱しています。

 

 https://testmysite.withgoogle.com/intl/ja-jp

投稿者 時刻: 0 件のコメント :

2018年4月26日木曜日

人を幸せにできないホームページは生き残れない。

ＷＥＢホームページ内部診断サービス

内部診断サービス内容

今後 、人を幸せにできないホームページは生き残れない時代がやってきても、

手遅れにならないよう今から準備をしませんか？

当方は、ホームページ公開後14年間、ホームページ業者やＳＥＯ業者に依頼

せず、自社独自で運営し検索エンジンのアルゴリズムの変化にも左右されない
 
経験をもとに
 
内部対策の欠点を診断し、実際にどこがダメなのかを指摘・アドバイスします。

従来の外部対策（被リンクを獲得するなど）よりも、

ずっと効果的なのが内部対策です。

内部対策さえしっかりやれば、自ら動かなくても自然と外部対策が施されます。

下手に自分で外部対策をしようとすると確実にペナルティを食らいます。

最初の設定が正しくされていなかったらいくら待っていても上位表示には

つながりません。

ストイックなSEO対策は長期的に

検索エンジンのアルゴリズムの変化にも左右されず、効果的です。

内部対策の診断内容

・タイトルタグ
・descriptionタグ
・H1タグ
・meta keywords
・キーワード比率
・headタグ行数
・URLの正規化がされているか
・ソースコード診断
・リンクエラー
・見出しタグ
・発リンク
・読み込み速度
・strongタグ
・画像の使い方
・キーワード候補提案など。
　
基本料金 50,000円

ご依頼内容によりご提案内容や見積もり金額は変わります。

どのように改善していけば良いのかを提案します。
 


相談もお気軽に！
 
〒579-8052
大阪府東大阪市上四条町 30-40 　 スマイル急便 　TEL 072-988-4610
gmail：smilekyuubin@gmail.com
投稿者 時刻: 0 件のコメント :

2018年4月11日水曜日

あなたは好きなことに関する情報を発信しませんか？


あなたは好きなことに関する情報を発信し、

「好き」が「得意」になり「強み」に育っていく。

その過程をどんどんブログやSNSで発信していくのです。

あなたのブログやSNSを読む人たちは、あなたが成長するに連れ、

あなたのことを、その分野の「専門家」「プロ」と認識するようになっていきます。

あなたの「好き」が「強み」にまで育ったとき、

あなたの周りの人たちは、

あなたにお金を払ってでも、あなたから商品やサービスを買いたいと願うようになります。

あなたの「好き」が「仕事」になった瞬間です。

あなたが「プロ」になった瞬間です。
投稿者 時刻: 0 件のコメント :

2017年12月14日木曜日

SSL CT技術（Certificate Transparency）

詳細をみると、「このウェブサイトの識別情報が Let’s Encrypt Authority X1 によって確認されました。証明書の透明性に関する情報がサーバーから提供されませんでした。」となっています。
TUI6
これは証明書がCT技術（Certificate Transparency）に対応していないためです。
調べてみると、Let’s Encryptのapacheプラグインの場合、まだCT機能までが盛り込まれていないようです。
参考：https://community.letsencrypt.org/t/will-you-support-certificate-transparency/222/4
Nginxの場合はnginx-ctを利用して、ソースインストールしたNginxにLet’s Encryptの –nginxプラグインを利用することで、簡単にCT導入もできる模様です。今すぐ、Let’s Encryptの証明書を利用してサイト運営するなら、このパターンでしょう。
今後のリリースに大いに期待です。


設定資料
  • nginxにnginx-ctプラグインをインストール
  • ct-submitコマンドの取得とビルド
  • CT情報の登録とSCTの取得
まずはnginxにnginx-ctプラグインをインストールします。
nginxのプラグインは動的に追加できないので、nginxをソースから再設定・リビルドする必要があります。
# nginx-ctプラグインのダウンロード
cd /tmp
wget https://github.com/grahamedgecombe/nginx-ct/archive/master.zip
unzip master.zip

# nginx-ctプラグインを有効化してNginxを再ビルド (OpenSSL 1.0.2以降も必要)
cd /usr/local/src/nginx-1.9.3
./configure --add-module=/tmp/nginx-ct-master --with-http_ssl_module 
--with-openssl=/usr/local/src/openssl-1.0.2d
make clean
make
sudo make install
次に、透かし入り証明書情報(Certificate Transparency)をサーバに登録・取得するためのコマンド、ct-submitをインストールします。
ビルドのためにGoも必要です。
cd /tmp
wget https://github.com/grahamedgecombe/ct-submit/archive/master.zip
unzip master.zip
cd ct-submit-master
go build
sudo install -s -m755 ./ct-submit-master /usr/local/bin/ct-submit
今度はct-submitコマンドを使って、X509証明書情報をCTログサーバに送信します。
※スクリプト先頭部分のKEY, CTSUBMIT, SCTS_DIR, $SCTS_DIRの許可件等は
適切に調整して下さい。
(一部のサーバからはエラーが返ってきたのでコメントアウトしました)
ct-submit.sh
#!/bin/sh
# Let's encryptから入手した fullchain.pem の場所
KEY=/etc/letsencrypt/live/shield.jp/fullchain.pem
# CT情報の保存先
SCTS_DIR=/etc/letsencrypt/live/shield.jp/scts
# ct-submitコマンド
CTSUBMIT=/usr/local/bin/ct-submit

echo 1
sudo sh -c "$CTSUBMIT ct.googleapis.com/aviator \
<$KEY \
>$SCTS_DIR/aviator.sct"
echo 2
sudo sh -c "$CTSUBMIT ct.googleapis.com/pilot \
<$KEY \
>$SCTS_DIR/pilot.sct"
echo 3
sudo sh -c "$CTSUBMIT ct.googleapis.com/rocketeer \
<$KEY \
>$SCTS_DIR/rocketeer.sct"
#echo 4
#sudo sh -c "$CTSUBMIT ct1.digicert-ct.com/log \
#<$KEY \
#>$SCTS_DIR/digicert.sct"
#echo 5
#sudo sh -c "$CTSUBMIT ct.izenpe.com \
#<$KEY \
#>$SCTS_DIR/izenpe.sct"
#echo 6
#sudo sh -c "$CTSUBMIT log.certly.io \
#<$KEY \
#>$SCTS_DIR/certly.sct"
指定したディレクトリにSCTファイルが出力されているか確認しましょう。
（SCT = Signed Certificate Timestamp：登録済み証明書タイムスタンプ）
sudo ls -al /etc/letsencrypt/live/shield.jp/scts
total 20
drwxr-xr-x 2 root root 4096 Nov 12 16:54 .
drwxr-xr-x 3 root root 4096 Nov 12 17:46 ..
-rw-r--r-- 1 root root  118 Nov 12 16:54 aviator.sct
-rw-r--r-- 1 root root  119 Nov 12 16:54 pilot.sct
-rw-r--r-- 1 root root  118 Nov 12 16:54 rocketeer.sct
以上で完了です。
あとはnginxを再起動してから、ChromeでHTTPSのURLにアクセスし、アドレスパーの緑の部分をクリックして確認しましょう。
以下のように、サーバからCT情報が提供されたということが表示されればOKです。
CT Provided

設定例

nginx.conf
  # nginx-ctプラグインを有効にしていないとエラーになります
  ssl_ct on;
  ssl_ct_static_scts /etc/letsencrypt/live/shield.jp/scts;

参考

Certificate Transparentのログサーバの一覧はどこから手に入る?
http://esupport.trendmicro.com/media/13357571/CT%20FAQ.pdf
答: 以下から入手可能。
http://www.certificate-transparency.org/known-logs



最後に

改めてnginx.confの設定内容です。少しずつ紹介した項目をひとまとめにしました。
nginx.conf
    #
    # HTTPS server
    #
    server {

      listen       443 ssl http2; # HTTP/2パッチを当てているため。
通常は http2 は不要
      server_name  shield.jp;

      ssl_certificate /etc/letsencrypt/live/shield.jp/fullchain.pem;
      ssl_certificate_key /etc/letsencrypt/live/shield.jp/privkey.pem;

      ssl_session_cache   shared:SSL:3m;
      ssl_buffer_size     8k;
      ssl_session_timeout 10m;

      # 1. 暗号方式の設定
      # (デフォルト) ssl_ciphers  HIGH:!aNULL:!MD5;
      ssl_ciphers "EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-
RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-
RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:
DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:
AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!
EXPORT:!DES:!MD5:!PSK:!RC4";
      ssl_prefer_server_ciphers  on;

      # 2. Logjam攻撃対策
      ssl_dhparam /etc/ssl/private/dhparam_4096.pem;

      # 3. Enable OCSP (Online Certificate Status Protocol) Stapling
      ssl_stapling on;
      ssl_stapling_verify on;
      resolver 8.8.4.4 8.8.8.8 valid=300s;
      resolver_timeout 10s;

      # 4. Enable HSTS (HTTP Strict Transport Security)
      add_header Strict-Transport-Security "max-age=31536000; includeSubdomains; preload";

      # 5. HPKP Settings
      add_header Public-Key-Pins 'pin-sha256="YLh1dUR9y6Kja30RrAn7JKnbQG/uEtLMkBgFF2Fuihg=";  
pin-sha256="GO8LTsdpBf/sLaUQ3/NPVCaGzZOmku+6iIBdeef9K2k="; max-age=2592000; includeSubDomains';

      # 6.証明書透かし (Certificate Transparency)設定
      ssl_ct on;
      ssl_ct_static_scts /etc/letsencrypt/live/shield.jp/scts;

      # 後略
}
投稿者 時刻: 0 件のコメント :

2017年6月25日日曜日

ホームページ導線の基本


ホームページの更新や公開時で悩んだ時、初心に戻ってみませんか？

投稿者 時刻: 0 件のコメント :

2017年6月23日金曜日

WEBアクセシビリティの重要性

ホームページ公開時にアクセシビリティチェックはされていますか？
日本WEBアクセシビリティ協会
や現在、無料でできる HARETTA(ハレッタ)は、入力したURLのアクセシビリティ適合度を
チェックするサイトを一度お試しください。



投稿者 時刻: 0 件のコメント :

2017年6月6日火曜日

Let's Encrypt によるサービス障害の報告

日本時間で 5月19日 15時52分～ 5月21日 15時40分 の約２日間において、
Let's Encrypt サービスサーバにおいて世界的なサービス障害が発生していました。

Let's Encrypt によるサービス障害の報告
https://letsencrypt.status.io/pages/incident/55957a99e800baa4470002da/591e962c4f9ef22239001819

その発生タイミングに該当しておられる自動更新設定は今一度ご確認を。
設定の不備やご利用サーバやネットワークのトラブルではないと推測されますが
今回の経験により下記のように改善いたしました。

  1. 更新スクリプトを実行するのは毎週でもよい。
(SSL証明書がまだ新しい場合はスキップ処理される)
　2.管理系のスクリプトは利用者への影響の少ない夜間に設定しておくことが一般的。
　　
投稿者 時刻: 0 件のコメント :

2017年4月24日月曜日

SEOにこだわっても成果は出ない




 本日、興味深いメールが届きました。

SEOとは、検索結果の上位表示させる為の施策なのですが
そのSEOにこだわる人ほど、成果が出ていない傾向があるわけです。

なぜでしょうか。

検索結果の上位に表示されればそれだけアクセスが増え、
売上も上がりやすくなるはずです。

しかし、結果はその正反対なわけです。

例えば、SEOにこだわる人は、
h1やmeta descriptionにキーワードを入れるとか、
パンくずやサイトマップを用意するとかそういったところにこだわります。

これらはすべてロボット向けの対策です。
しかも、Googleが昔に一部披露したアルゴリズムです。

ですが、グーグルがユーザーファーストを掲げる時代に
これらの「ロボット対策」は古さを感じます。

確かにロボットに正しく認識してもらう努力でマイナスになることはないでしょうが、
世の中やグーグルの動きを見ていると、もはやそんなフェーズではないのです。

なぜなら、グーグルは以前から人工知能によってユーザーの動向を学習させ、
検索結果に反映させるアルゴリズムを稼働させているからです。

→ http://wired.jp/2016/03/13/ai-is-transforming-google-search/

急速に進化するテクノロジーの前で
このようなSEOの考え方は致命的に時代遅れです。

これからはコンテンツの時代です。

"ロボット"が見るところではなく、
”ユーザー"から見えるところにリソースを注いだほうが
効率よく目的を達成できますね。


それではまた。
投稿者 時刻: 0 件のコメント :

2017年3月20日月曜日

インターネットの検索結果上位（1位）でも売上げに結びつかない理由

今、お悩みのあなたへ。

インターネット検索で上位にタイトルや説明文 が表示できていればクリックされ

アクセスがあり、売上が上がると思っていますか？ 答えはNOです。

 ホームページからのお問い合わせがないあなたへ。

手間暇かけてHPを作った（作ってもらった。）

検索エンジンにも登録した。

なのに閑古鳥

もし、問い合わせがない理由 をお知りになりたければ

例えば、

Yahoo!プロモーション広告(リスティング広告)

Googleアドワーズ広告とは?


を試して見るのもいいのかも知れません？

Yahooリスティング広告やGoogleアドワーズ広告を利用しても良い結果がでなければ

ホームページを見直す必要があるのではないでしょうか？

本来、ホームページは無料で作り無料でインターネット上で公開できてあたりまえ

でも、そこには「それぞれの出来ない部分」に対してのビジネスが生まれています。

今後インターネット検索最大手Googleは益々、ホームページの内容（品質）にこだわり

過去のＳＥＯ【上位表示する為だけにお金を払う？） は今後通用しない確立した時代が

もうすぐやってきます。


いくら検索結果を上位表示を狙いタイトルや説明文だけを変えても駄目です。

売らない。、押し売りをしない。

ユーザー目線（興味をもって貰える）に合うホームページ。

お客様から是非あなたから買いたい。

あなたからのサービスを是非受けたい。

と思ってもらえるようなホームページではないでしょうか？

そうする事によりホームページにお金をかけなくても自然に上位表示します。

その為には日々自分で課題を見つけて改善や努力も必要ですが・・・。


例えばうどん屋さんの例を少しお話すると

ある山奥に一件のうどん屋さんがありました。

外観を見る限りではとても流行りそうでないお店でした。

ところがある「キッカケ」で行列ができるようになりました。

ある「キッカケ」とは何だったと思いますか？

そこの主人がパソコンを使い素人ながらホームページを作って公開したからです。

もともとそこの主人はうどん作りの名人で腕には自信があったようです。

あなたはどう感じましたか？




難しいとは思いますが世の中のホームページは

あまりにも「売り」を全面に出したホームページが多すぎるのではないでしょうか？



あくまでも1ページ1キーワードに徹して「タイトル」「説明文」「ページ本文」が一致していて

ユーザーが興味を持ちクリックされ他社との違いが明確にわかり問い合わせに繋がるような

ホームページ作りが好まれます。

尚、安売りをモットーにしてるのなら話しは別ですが、他社との違いが明確に伝えられなく

同じような商品やサービスなら安い業者を選ぶのではないでしょうか？

今、一度 Google検索エンジン最適化スターターガイド 

をじっくりお読みくだってみられたらいかがでしょうか？

また弊社公式ホームページのコラムも参考にされ今後の繁栄をお祈り申し上げます。

https://www.smile-kyuubin.jp/colomn/

今後大きな変動が起こっていくものの、やはり最終的に評価されるのは

「ユーザーにとって有益な情報」です。

Googleはユーザーファーストを追求する企業だということを常に忘れず、

小手先のテクニックに頼らず、テキスト・動画関係なく良質なコンテンツを作る事を心がけましょう。









投稿者 時刻: 0 件のコメント :

2016年11月18日金曜日

2016年11月18日より常時ＳＳＬ（暗号化）へ

2016年も残りあとわずかですが皆さんはいかがお過ごしでしょうか？ 2007年夏にホームページを立ち上げて来年夏で10年を迎えればと考えて2016年11月18日より常時ＳＳＬ（暗号化）に取り組んでいければと思っておりま す。個人情報の大切さ。インターネットの先はどんな人？人間社会の中でお会いしてお話しをするより難しい伝えたい文字入力の大切さ。 日々精進を重ねてお一人暮らしのお力になれればとの想いホームページの更新に可能な限り努めていければと考えております。
投稿者 時刻: 0 件のコメント :

2016年9月16日金曜日

ホームページ制作やSEOについて

あなたがもし、これからあなたや会社のホームページを作るとすればどうしますか？ ホームページの会社に依頼しますか？ あなたにホームページとはの豊富な知識があればこの先は役に立ちません。 知識がなければ知識のある人や会社？に問い合わせをする？そこまでは普通の行動かも知れません。 でも、少しそこで考えてみて下さい。 たとえば、あなたが全くの素人だった場合、ホームページ会社やSEO会社？に問い合わせをする？ そこまでは普通のどこにでもある行動や判断かも知れません。 そこから先はあなたならどういう行動や判断しますか？ 豊富な知識の持ち主なら話しは別ですが、ホームページ会社やSEO会社の技術レベルは判断できません。 知識のある方なら少し話しをして自信のあるホームページ会社やSEO会社なら上手くいくかも知れません。 ほとんどのホームページ会社やSEO会社は素人のあなたがいいのです。 どうか騙されないように用心してください。 結局、もしご覧くださっているあなたが素人なら、業界以外の人に聞いてみてはいかがでしょうか？ 業界の人はあなたの事を聞いてる振りをして、結局自分の都合しか言いません。 どうか、あなたの大切なお金を大切にして、あなたの大切な人生を送ってくださいね。 参考になるかも知れませんがもしよろしければコラムを覗いてみてください。
投稿者 時刻: 0 件のコメント :

2016年8月26日金曜日

Googleモバイル検索、「スマホ対応」ラベルを廃止

米Google は2016年8月23日、モバイル検索結果において同社のモバイル対応基準を満たしたページに表示してきた 「Mobile Friendly（スマホ対応）」ラベルを削除する方針を明らかにした。
投稿者 時刻: 0 件のコメント :
登録: 投稿 ( Atom )