ご連絡ありがとうございます。
不具合に気づいてませんでした。
値の存在確認を追加しました。
https://github.com/yhira/cocoon/commit/6517b9a2dd95f5aef45b94decdabfc5db440fb94

https://github.com/yhira/cocoon/commit/6517b9a2dd95f5aef45b94decdabfc5db440fb94

こちらの不具合修正では不十分なので、改めて問題点を整理します。

まず、現時点で作成されているカテゴリー・タグのタームメタデータには、

1. 'the_category_noindex'
2. 'the_tag_noindex'

の両方存在してしまっている点がひとつの不具合原因となっています。

よって、二重に存在するメタデータを統一する、または一括取得後に'the_category_noindex'のうちカテゴリーに紐づいている設定値のみ＆'the_tag_noindex'のうちタグに紐づいている設定値のみで選別するなど、必要十分な状態になるよう修正しないといけません。

続いて、設定値の保存・更新における不具合を修正する必要がありますが、インデックス設定はチェックボックスなので、今の仕様のまま単純に保存データのキーだけでは設定の存在を判定することができません。

動作的には、チェックボックスからチェックを外す場合は保存されず、チェックが入ったまま変更できなくなります。

この不具合を修正した上で、二重に存在するメタデータを統一する場合には、メタデータの保存先等も調整する必要が出てくるかもしれません。

続いて、設定値の保存・更新における不具合を修正する必要がありますが、インデックス設定はチェックボックスなので、今の仕様のまま単純に保存データのキーだけでは設定の存在を判定することができません。

そうでした。チェックされない場合保存されないので現在の仕様にしたんでした；失礼しました。
なので、カテゴリー画面ではカテゴリーの設定、タグ画面ではタグの設定のみ保存されるように修正してみました。
https://github.com/yhira/cocoon/commit/3eb3cdc80650fc53b7a8b599657e86e1fbe113b4

投稿者:: @lococo

よって、二重に存在するメタデータを統一する、または一括取得後に'the_category_noindex'のうちカテゴリーに紐づいている設定値のみ＆'the_tag_noindex'のうちタグに紐づいている設定値のみで選別するなど、必要十分な状態になるよう修正しないといけません。

これについては、the_category_noindexが1になるデータを引っ張り出してきて、

SELECT * FROM wp_termmeta
WHERE (meta_key = 'the_category_noindex') AND (meta_value = 1)

最終的には、以下のような値を取得しているんですけど、これはカテゴリーに紐づいている設定値にはなりませんでしょうか。

SELECT DISTINCT GROUP_CONCAT(term_id) AS ids FROM wp_termmeta 
WHERE (meta_key = 'the_category_noindex') AND (meta_value = 1)

カテゴリー画面ではカテゴリーの設定、タグ画面ではタグの設定のみ保存されるように修正してみました。

確認しました。

修正ありがとうございます。

最終的には、以下のような値を取得しているんですけど、これはカテゴリーに紐づいている設定値にはなりませんでしょうか。

wp_termmetaのデータテーブルは、全てのタクソノミー下にあるタームで共用している点を考慮する必要があります。

例えば、添付画像のようにカテゴリー・タグ作成画面にも案内がありますが、カテゴリーやタグを整理するためにカテゴリー⇔タグを変換したり、新たなタクソノミーでより細かい分類に仕分けする場合などがあります。

『Cocoon』というカテゴリーで「インデックスしない」にチェックを入れていたとすると、データベース上では'the_category_noindex'=1です。

そのまま『Cocoon』をタグに変換した後、新たに'the_tag_noindex'でインデックスさせる設定なら、データベース上では

• 'the_category_noindex'=1
• 'the_tag_noindex'=0

となります。

「タグである『Cocoon』のタームIDに対して、'the_tag_noindex'の設定値を取得する。」という場合には問題ありませんが、おっしゃっている現在の方法で一括データを取得しようとすると、'the_category_noindex'と'the_tag_noindex'の両方が対象となります。

そして、現在のタグとしての'the_tag_noindex'=0は該当しないものの、'the_category_noindex'=1が該当し、カテゴリーとして処理されてしまいます。

この例のような問題から、

二重に存在するメタデータを統一する、または一括取得後に'the_category_noindex'のうちカテゴリーに紐づいている設定値のみ＆'the_tag_noindex'のうちタグに紐づいている設定値のみで選別するなど

の修正方法を挙げた次第です。

お恥ずかしながら、この機能については、今初めて知りました。
元々不具合があったのが問題なんですが、こういった変換については全く想定していませんでした。

例えば「Cocoon」というカテゴリを作成して、noindexを有効にするとデータベース上では以下のようにデータが保存されます。

その後、「Cocoon」というカテゴリを「変換」機能を用いてタグに変更した場合、以下のように値が保存されてしまい、その状態でget_noindex_category_idsをした場合、the_category_noindexの値を引っ張ってきて問題ということだったんですね。

get_noindex_category_ids、get_noindex_tag_idsを使用しているのは、検索してみると以下のようなサイトマップ出力処理の部分だけで
https://github.com/yhira/cocoon/blob/b3bfa849aa647ba4aee39649d91c2edfdda0e22c/functions.php#L284
以下のようなWordPressデフォルトのサイトマップを表示して動作確認しようとしたところ、404ページになってしまいます（他のテーマにしても同じでした）。
https://wp-cocoon.com/wp-sitemap.xml
なにか仕様変更があったんでしょうか。

それとは別に、関数で値を取得した後に、以下のようにカテゴリーならカテゴリーに紐ついてるものだけに選別する処理を後で加えようと思います。

よって、二重に存在するメタデータを統一する、または一括取得後に'the_category_noindex'のうちカテゴリーに紐づいている設定値のみ＆'the_tag_noindex'のうちタグに紐づいている設定値のみで選別するなど、必要十分な状態になるよう修正しないといけません。

以下のようなWordPressデフォルトのサイトマップを表示して動作確認しようとしたところ、404ページになってしまいます（他のテーマにしても同じでした）。
https://wp-cocoon.com/wp-sitemap.xml
なにか仕様変更があったんでしょうか。

https://wp-cocoon.com/sitemap.xml

「Google XML Sitemaps」プラグインを使用されていると思いますが、このプラグインではWordPressコアのサイトマップを無効化するようになっています。

add_filter('wp_sitemaps_enabled', '__return_true', 11);

リライトルールによっては404エラーのままかもしれませんが、一応子テーマ等でフックから有効化することはできます。

ありがとうございます。
確かに。当サイトに関しては、それが原因だと思います ? 
ただ、プラグインを何もインストールしていないローカル環境でも、同様の症状が出たのでWordPressの問題と勘違いしてしまいました。
おそらく、僕のローカル環境側の何かしらの問題だと思います。
試しに、WEB上にまっさらなサイトを作成して、/sitemap.xmlを表示させたら問題なく表示されました。

カテゴリーとタグについては、選別処理を追加してみました。
https://github.com/yhira/cocoon/commit/db59550c3c2175d31bb5bd0136e984ec58a9fccc

確認しました。

修正ありがとうございます。

ただ、プラグインを何もインストールしていないローカル環境でも、同様の症状が出たのでWordPressの問題と勘違いしてしまいました。

おそらくですが、表示設定の「検索エンジンがサイトをインデックスしないようにする」にチェックが入っているのではないでしょうか。

ご確認ありがとうございます。

おそらくですが、表示設定の「検索エンジンがサイトをインデックスしないようにする」にチェックが入っているのではないでしょうか。

ローカル環境（旧Local by Flywheel）を確認してみましたが、チェックは入っていませんでした。
通常とは違う気になる点といえば、一般的な404ページではなくて、添付画像のような404ページが出ることです。

見た目も違うので、おそらく環境の問題と思うのでもうちょっと調べてみます。
ありがとうございます。