XML sitemapのPing送信が実は役立たずではなかった話

もしも・・・子サイトマップのURLでPingしたら

2023年6月のGoogleのブログによると、サイトマップのPing送信が非推奨扱いになったようです。(Googleの) Pingの送信先(エンドポイント)自体が無効になるようなので、このページで紹介しているPing送信は、もはや本当に役立たずです。

XML sitemapとは、ウェブサイト内の文章コンテンツのページURLや画像や動画などのコンテンツのURLを検索エンジンに通知するためのファイルです。Ping送信とは、XML sitemapファイルを更新したことを検索エンジンに伝えるための手法です。これらはウェブサイト運営者が検索エンジン最適化(SEO)を行う際に重要な役割を果たすと言われています。

しかし、XML sitemapのPing送信が本当に効果的なのか疑問視する声もあります。 特に親子型のXML sitemapをPing送信してもコンテンツページが記載されている子XML sitemapがクロールされない問題は多くのウェブサイトのオーナーが気付いています。そこで、このPing送信の問題について実際に試してみることにしました。

実験方法 1

今回、このサイト「がとらぼ(inta.net)」で実験しました。このウェブサイトではWordPressというCMS (コンテンツ管理システム)を使用しており、「Google XML Sitemaps」というプラグインでXML sitemapファイルを生成しています。

このプラグインでは、「通知」設定で各種検索エンジンへPing送信するかどうか選択できます。私はこの設定をオフ(Ping送信しない)からオン(Ping送信する)へ変更しました。オンにすると、このプラグインは記事の公開/更新時や定期時にXML sitemapのサイトマップインデックス (親XML sitemap)をGoogleにPing送信します。

そして、WordPressで新しい記事を公開(更新)してプラグインによる自動Ping送信を行いました。Google Search ConsoleというGoogleが提供するオンラインツールでは、XML sitemapファイルの状態や最新の読み込み日時、エラーなどを確認することができます。

この実験では、Ping送信することでGoogle検索エンジンが親XML sitemapファイルと子XML sitemapを早くクロールしようとするかクロールしないのかを検証します。
以上が実験方法です。

実験結果 1

実験は2022年12月1日から2022年12月31日までの31日間行いました。その間に「がとらぼ(inta.net)」では6件の新規記事を投稿しました。Ping送信から1時間以内にXML sitemapがクロールされたことをGoogle Search Consoleの最終読み込み日時で確認しました。
実験結果は以下の表にまとめました。

記事投稿日時親sitemap子sitemap
112月1日更新あり更新無し
212月6日更新あり更新無し
312月13日更新あり更新無し
412月18日更新あり更新無し
512月19日更新あり更新無し
612月31日更新あり更新無し

表を見ると、サイトマップインデックスをPing送信することによってサイトマップインデックス(親XML sitemap)は即時から数分以内にクロールされるものの子XMLサイトマップはクロールされないことが判ります。
なお、子XML sitemapがクロールされて最終読み込み日時が更新されるまでに何日もかかりますが、次の新しい投稿までに更新されないため実際に何日かかるかを調べることはできませんでした。
また、Ping送信しなかった期間にはSearch Consoleの「読み込まれたサイトマップ」でサイトマップインデックスの最終読み込み日時が更新されませんでした。

実験結果に基づく結論 1

実験結果1から、以下のような結論を導くことができます。

  • 通常のXML sitemapのPing送信はサイトマップインデックスを早く認識させる効果がある
  • 通常のXML sitemapのPing送信は子XMLサイトマップを早く認識させる効果はない

子XML sitemapをPing送信する実験

「Googleにサイトマップを送信する」というドキュメント
Google検索セントラルの「サイトマップの作成と送信」という記事によると
https://www.google.com/ping?sitemap=FULL_URL_OF_SITEMAP
というURLにPing送信すると書かれています。旧Google Webmaster Tools時代は
http://www.google.com/webmasters/sitemaps/ping?sitemap=FULL_URL_OF_SITEMAP
というURLが使われてしました。この古いURLは、WordPressのXMLサイトマップ出力プラグインとしては最もメジャーな(Google) XML Sitemapsプラグインが現在も使用しています。このURLは、応答があるので有効と思われます。

ターミナルやコマンドラインでコマンドを入力してPing送信を行ってみました。

$ curl "https://www.google.com/ping?sitemap=https://intaa.net/wp-sitemap.xml"
<html><meta http-equiv="content-type" content="text/html; charset=UTF-8">
<head><title>Google Webmaster Tools
-
Sitemap Notification Received</title>
<meta name="robots" content="noindex, noodp">
<script src="https://ssl.google-analytics.com/urchin.js" type="text/javascript">
    </script>
<script type="text/javascript">
      _uacct="UA-18009-2";
      _utcp="/webmasters/";
      _uanchor=1;
      urchinTracker();
    </script></head>
<body><h2>Sitemap Notification Received</h2>
<br>
Your Sitemap has been successfully added to our list of Sitemaps to crawl. If this is the first time you are notifying Google about this Sitemap, please add it via  <a href="http://www.google.com/webmasters/tools/">http://www.google.com/webmasters/tools/</a>  so you can track its status. Please note that we do not add all submitted URLs to our index, and we cannot make any predictions or guarantees about when or if they will appear.</body></html>

この例ではサイトマップURLはhttps://intaa.net/wp-sitemap.xml (サイトマップインデックス)にPing送信しています。このような応答を得ることができればPing送信に成功しています。

実験結果 2

実験は2023年1月2日にサイトマップインデックスを除く個別8つの子XML sitemapにPing送信を行いました。Ping送信から3分以内にXML sitemapがクロールされたことをGoogle Search Consoleの最終読み込み日時で確認しました。
実験結果は以下の表にまとめました。

子sitemap最終読み込み日時更新の有無
12023/01/02更新あり
22023/01/02更新あり
32023/01/02更新あり
42023/01/02更新あり
52023/01/02更新あり
62023/01/02更新あり
72023/01/02更新あり
82023/01/02更新あり

表を見ると、子XML sitemapをPing送信することによって即時から3分以内にクロールされることが判ります。
また、子XML sitemapをPing送信することによって、他の子XML sitemapの最終読み込み日時が更新されることはありませんでした。

実験結果に基づく結論 2

実験結果2から、以下のような結論を導くことができます。

  • 子XML sitemapのPing送信は子XML sitemapを素早く認識させる効果がある

Search ConsoleでPing送信したサイトマップを確認
Pingを送信して画像を取得したのは2023年1月2日です。
この「がとらぼ(inta.net)」の子サイトマップは8個ありますが、この画像の取得時点ではその内の3つだけPing送信して3分後にSearch Consoleのサイトマップレポートを表示しました。つまり3つの子XML sitemapの最終読み込み日時が2023/01/02になっています。
最終的には上の実験2のとおり全ての子XML sitemapにPingを行い最終読み込み日時が2023/01/02になったことを確認しています。

まとめ

この記事では、XML sitemapのPing送信によってGoogleがXML sitemapを素早く認識するかどうかを実際に試してみました。

その結果、Ping送信したURLのXML sitemapだけをすぐにクロールして検索エンジンがXML sitemapファイルを早く認識し、Ping送信していないURLのXML sitemapはすぐにはクロールされないことがわかりました。これは親子型のXML sitemapでは部分的にしか素早く認識されないことを意味します。
また、サイトマップインデックスをPing送信した場合にはコンテンツURLを記載した子XML sitemapがクロールされないため、そのPing送信には意味がないことがわかりました。
また、Google Search ConsoleユーザーがPing送信を疑問視している内容とも一致する結論を導くことができました。

したがって、XML sitemapのPing送信を有効なものにするのであれば子XML SitemapのPing送信が欠かせません。
今後、親子型XML sitemap出力ツール(プラグイン)を作成しPing送信機能を実装するなら、公開/更新されたコンテンツURLを含む子サイトマップのURLをPing送信するべきです。

もしあなたがウェブサイト運営者ならば、ぜひ子XML sitemapのPing送信を活用してみてください。

シングルボードコンピュータでAgent DVRを動かしてNVRサーバにする 後編

もしもOrange Pi Zero 2にハードディスクをつないだら・・・

前回、シングルボードコンピューターのOrange Pi Zero 2用にAgent DVRのビルド+インストールとカメラの登録を行った。今回はその続きで映像データ保存用のストレージの用意と登録。

廉価な小型低性能のシングルボードコンピュータにはSATAなどのハードディスクを接続する端子が無いことが多い。NVRサーバでカメラの映像を録画する場合、NFSなどで別のホストに録画データを保存する方法もありますが、それならそもそもシングルボードコンピュータをNVRサーバにするまでもなくそのホストをNVRサーバにすれば良さそう。今回は、シングルボードコンピュータのUSB端子に外部HDDを接続し録画データを保存する。

Amazon商品画像
センチュリー スライディング裸族 SATA6G CSDRU3B6G

販売価格: 4,158 円

(2023年01月02日 6:00時点の参考価格)

SATA接続タイプのSSDや2.5インチHDDを接続する場合はUSB1コネクタとSATA+電源の中華アダプタが500円程度から購入できる(正常に動作するかは無保証)。3.5インチHDDはUSBアダプタ単体で駆動させるには電源が不適合なのでHDDスタンドやHDDドックと言われる製品を使うのが無難。上の写真にも写っている「スライディング裸族」は個人的にはとてもオススメ。HDDの縦挿しタイプは軽いHDDだと浮き上がりが発生して接続が不安定になったりHDD背面の基板部分にホコリが溜まることがあるので埃よけが必要だが横スライド挿しの「スライディング裸族」はこれらの欠点が改善されています。SATAは端子部分が3.5インチ2.5インチ共通なので2.5インチHDDでも使えます。でも、スライディング裸族はちょっとお高めかも。

ハードディスクのフォーマットとマウント

HDDスタンドから生えているUSBケーブルをシングルボードコンピュータのUSB端子に接続する。HDDスタンドの電源をオンにする。

# lsusb    USBの接続済みデバイスの確認
Bus 008 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 002: ID 174c:1053 ASMedia Technology Inc. CSDRU3B6G   何かのデバイスが検知された
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

# ls /dev    デバイスの確認 この例ではsdaがハードディスク
autofs           fuse       loop4         pts             tty    tty22  tty37  tty51  tty9     vcs2   vcsu4
block            gpiochip0  loop5         random          tty0   tty23  tty38  tty52  ttyBT0   vcs3   vcsu5
bsg              gpiochip1  loop6         rfkill          tty1   tty24  tty39  tty53  ttyBT1   vcs4   vcsu6
btrfs-control    hugepages  loop7         rtc             tty10  tty25  tty4   tty54  ttyS0    vcs5   vhci
bus              hwrng      loop-control  rtc0            tty11  tty26  tty40  tty55  ttyS1    vcs6   video0
cec0             i2c-0      mapper        sda             tty12  tty27  tty41  tty56  ttyS2    vcsa   watchdog
char             i2c-1      media0        sg0             tty13  tty28  tty42  tty57  ttyS3    vcsa1  watchdog0
console          initctl    mem           shm             tty14  tty29  tty43  tty58  ttyS4    vcsa2  wcn_op
core             input      mmcblk1       slog_wcn0       tty15  tty3   tty44  tty59  ttyS5    vcsa3  zero
cpu_dma_latency  kmsg       mmcblk1p1     slog_wcn1       tty16  tty30  tty45  tty6   uhid     vcsa4  zram0
cuse             lirc0      mqueue        snd             tty17  tty31  tty46  tty60  uinput   vcsa5  zram1
disk             log        net           stderr          tty18  tty32  tty47  tty61  uleds    vcsa6  zram2
dri              loop0      null          stdin           tty19  tty33  tty48  tty62  urandom  vcsu
ecryptfs         loop1      ppp           stdout          tty2   tty34  tty49  tty63  v4l      vcsu1
fd               loop2      psaux         sunxi-reg       tty20  tty35  tty5   tty7   vcs      vcsu2
full             loop3      ptmx          sunxi_soc_info  tty21  tty36  tty50  tty8   vcs1     vcsu3

# fdisk -l  既存のパーティションを表示
Disk /dev/mmcblk1: 14.84 GiB, 15931539456 bytes, 31116288 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xe8ce0794

Device         Boot Start      End  Sectors  Size Id Type
/dev/mmcblk1p1       8192 30801919 30793728 14.7G 83 Linux    ←microSDカードのOSを含むメイン(/ ルート)のファイルシステムのパーティション

メモリディスクなどのパーティションも表示される(省略)

# fdisk /dev/sda    /dev/sdaのハードディスクにパーティションを設定する

Welcome to fdisk (util-linux 2.36.1).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.

The device contains 'isw_raid_member' signature and it will be removed by a write command. See fdisk(8) man page and --wipe option for more details.

Device does not contain a recognized partition table.
Created a new DOS disklabel with disk identifier 0x56babc2f.

Command (m for help): p     /dev/sdaハードディスクの既存パーティションを表示
Disk /dev/sda: 232.89 GiB, 250059350016 bytes, 488397168 sectors
Disk model: 8AS
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 33553920 bytes
Disklabel type: dos
Disk identifier: 0x56babc2f


Command (m for help): n     新規パーティションの作成
Partition type
   p   primary (0 primary, 0 extended, 4 free)
   e   extended (container for logical partitions)
Select (default p): p     プライマリを選択
Partition number (1-4, default 1): 改行( or 1)    パーティション番号1を選択
First sector (65535-488397167, default 65535): 改行( or 65535)    最初のセクタ65535を指定
Last sector, +/-sectors or +/-size{K,M,G,T,P} (65535-488397167, default 488397167): 改行( or 488397167)    最後のセクタ488397167を指定

Created a new partition 1 of type 'Linux' and of size 232.9 GiB.
Partition #1 contains a isw_raid_member signature.

Do you want to remove the signature? [Y]es/[N]o: y    よく判らないRAID用署名があったようなので削除させる許可でYを指定

The signature will be removed by a write command.

Command (m for help): p    パーティションを表示して確認
Disk /dev/sda: 232.89 GiB, 250059350016 bytes, 488397168 sectors
Disk model: 8AS
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 33553920 bytes
Disklabel type: dos
Disk identifier: 0x56babc2f

Device     Boot Start       End   Sectors   Size Id Type
/dev/sda1       65535 488397167 488331633 232.9G 83 Linux     パーティションを作成できた

Filesystem/RAID signature on partition 1 will be wiped.

Command (m for help): w    設定したパーティションを保存して終了
The partition table has been altered.
Calling ioctl() to re-read partition table.
Syncing disks.

# mkfs.ext4 /dev/sda1    作成したパーティションをext4でフォーマットする
mke2fs 1.46.2 (28-Feb-2021)
Creating filesystem with 61041454 4k blocks and 15261696 inodes
Filesystem UUID: 67ddf6bd-0959-4b78-a186-efcf6c0af82f
Superblock backups stored on blocks:
        32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
        4096000, 7962624, 11239424, 20480000, 23887872

Allocating group tables: done
Writing inode tables: done
Creating journal (262144 blocks):
done
Writing superblocks and filesystem accounting information: done    終了

# fdisk -l    パーティションを表示
Disk /dev/mmcblk1: 14.84 GiB, 15931539456 bytes, 31116288 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xe8ce0794

Device         Boot Start      End  Sectors  Size Id Type
/dev/mmcblk1p1       8192 30801919 30793728 14.7G 83 Linux


Disk /dev/zram0: 492.06 MiB, 515960832 bytes, 125967 sectors
Units: sectors of 1 * 4096 = 4096 bytes
Sector size (logical/physical): 4096 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/zram1: 50 MiB, 52428800 bytes, 12800 sectors
Units: sectors of 1 * 4096 = 4096 bytes
Sector size (logical/physical): 4096 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/sda: 232.89 GiB, 250059350016 bytes, 488397168 sectors
Disk model: 8AS
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 33553920 bytes
Disklabel type: dos
Disk identifier: 0x56babc2f

Device     Boot Start       End   Sectors   Size Id Type
/dev/sda1       65535 488397167 488331633 232.9G 83 Linux

# mkdir /rec    どこでも良いがハードディスクのマウント場所となるディレクトリ /rec を作成

# mount /dev/sda1 /rec    ハードディスクに作成したext4ファイルシステム/dev/sda1 を /rec にマウントする

# df -h    ファイルシステム等のマウント状態を確認する
Filesystem      Size  Used Avail Use% Mounted on
udev            422M     0  422M   0% /dev
tmpfs            99M  840K   98M   1% /run
/dev/mmcblk1p1   15G  3.9G   11G  27% /
tmpfs           493M     0  493M   0% /dev/shm
tmpfs           5.0M  4.0K  5.0M   1% /run/lock
tmpfs           493M     0  493M   0% /tmp
/dev/zram1       49M   28M   18M  61% /var/log
tmpfs            99M     0   99M   0% /run/user/1001
/dev/sda1       229G   28K  217G   1% /rec    マウント完了。これで出来た

今回は手動でハードディスクのマウントを行ったが、設定ファイルに書いた訳ではないのでシステムを再起動するとマウントされない状態になる。
/etc/fstabなどにマウント情報を書き込むというのが普通かと思われますが、USBのリムーバブルディスクを/etc/fstabに書くのは気が引けるので、/etc/rc.localに手動マウントと同じコマンドを書いてシステム起動後に毎回マウントする。exit 0の前の行あたりに /usr/bin/mount /dev/sda1 /rec という1行を挿入する。

# mkdir /rec/agent   これがメイン
# mkdir /rec/archive   これは無くても可かも
# mkdir /rec/images   これは無くても可かも

ハードディスクの /rec 下にサブディレクトリを作成しておく

Agent DVR用ストレージをハードディスクに設定する

シングルボードコンピュータでAgent DVRを使う 18
メイン画面左上のアイコンをクリック。
メニュー画面で「設定」をクリック。

シングルボードコンピュータでAgent DVRを使う 19
設定の右上のドロップダウンから「ストレージ」を選択する。

シングルボードコンピュータでAgent DVRを使う 20
ストレージの設定の「構成、設定」の「 」をクリック。

シングルボードコンピュータでAgent DVRを使う 21
Agent DVRインストール直後の初期Pathが登録されているが、Orange Pi の場合はmicroSDカードの /root 下になっている。当然、microSDカードを映像(動画/画像/音声)の保存先としては使えないのでNFSなどで別ホストのストレージに保存するか、外付けのハードディスクかSSDに保存する。それがこの記事の主題。
常識的には先ず不要なmicroSDカードの/root下というPathを削除したいところだが、このストレージの設定には最低1つのPathが登録されている必要があるらしく、1つしか登録されていない状態でそのPathを削除はさせて貰えない。そこで、先にハードディスクのPathを登録してから/root/・・・のPathを削除するという流れ。
「追加」をクリック。

シングルボードコンピュータでAgent DVRを使う 22
意味のない「確認」画面が表示されるので「OK」をクリック。

シングルボードコンピュータでAgent DVRを使う 23
ストレージの設定画面の一番上の「アドレス」に先に作成したディレクトリ /rec/agent/ を入力する。
「ストレージの管理」の「管理」スイッチをOnにする。
「記録」の「アーカイブの場所」と「画像の場所」に上で作成したサブディレクトリのPathを入力する。(空でも良いかも)
右下の「OK」をクリック。

シングルボードコンピュータでAgent DVRを使う 24
ストレージの画面に戻ると /rec/agent/ が登録されていることが確認できる。これで最初から登録されていたmicroSDカードの保存場所/root/・・・を削除可能になる。「」をクリックで削除する。

シングルボードコンピュータでAgent DVRを使う 25
メイン画面左上のアイコンをクリック。
メニュー画面で「デバイスの編集」(カメラの設定変更)をクリック。

シングルボードコンピュータでAgent DVRを使う 26
登録済みのカメラのリストから変更したいカメラの「」(編集)をクリックする。
複数のカメラを登録済みの場合は全てのカメラを順に設定変更する。(以下)

シングルボードコンピュータでAgent DVRを使う 27カメラの編集画面右上のドロップダウンメニューを「全般的」から「ストレージ」に変更。

シングルボードコンピュータでAgent DVRを使う 28
「位置」と「フォルダ」を適切に設定する。
右下の「OK」をクリック。

複数カメラを登録済みなら全てのカメラで同様に設定変更する。
Agent DVRの設定でカメラ登録より先にストレージの登録をしていれば不要な設定ですが、このようにAgent DVR全体としてのストレージの設定とカメラ別の保存場所の設定があるということを知っておくことは大事。

録画モードの設定

シングルボードコンピュータでAgent DVRを使う 29
カメラの設定ついでに、カメラの編集画面右上のドロップダウンメニューを「全般的」から「検出器」に変更。
検出機能のスイッチを有効(On)にする。
画面内で動く物体を検知する範囲を編集する。初期値は画面全体。一部を検出対象から除外する場合は「」(消しゴム)アイコンを選択して除外したい部分をクリックする。青く塗られている範囲が検出対象のエリアなので勘違いなく。 「検出器」のドロップダウンメニューで初期値の「なし」から「単純」等に変更する。非力なシングルボードの場合は「単純」が無難。単純だと画面内の指定範囲で動きがあれば録画が始まるというシンプルな動作。高性能なPCであればAI系の検出器を使うという選択肢がある。
設定したら右下の「OK」をクリック。

シングルボードコンピュータでAgent DVRを使う 30
設定を確認するために左上の「」(ビデオカメラ)アイコンのドロップダウンメニューから「ライブカメラ」をクリック。
カメラーのプレビュー画面が表示されるので動くものが映るのを待つ。画面内で動きがあったときに右上に が表示されて録画が始まることを確認。(画面内から動くものが消えて暫くして録画が停止することも)

OrangePi Zero 2は非力な部類のシングルボードコンピュータだが1週間ほど動かしてみた感想としては予想外に安定しているというのを先ず挙げたい。そして、以前に超非力なノートPCとWindowsでAgent DVRを動かしたときより遥かに動作が軽め。もちろん高性能なPCには負ける筈だがカメラの台数が少なめであればこれで十分といえる。ネットワーク通信の怪しい中華NVRボードよりは安心して使えるし。ただし、Agent DVRは本格的に使おうとすると有料ライセンスが必要になるので本当に小規模で大人しく使うのでなければ利用継続にはそれなりにお金がかかることになるので注意。Agent DVRのインストール時に(自動)ビルドしたffmpegが遅延少なめで良い感じ。

関連記事:
Up