WordPress.orgプラグイン審査の全手順｜提出・差し戻し対応・SVN公開まで

全体の流れを先に把握する
提出前に必ずやること（ここで9割決まる）
1. 公式ガイドラインにざっと目を通す
2. WordPress.orgアカウントと2FAの準備
プラグインヘッダーを整える
readme.txtを作成する
Plugin Checkで検査する——提出前の最重要タスク
提出用ZIPを作成する
1. 正しい構成
2. ZIPに含めないもの
提出する
1. slugは一生変わらない——ここだけは慎重に
2. 審査の待ち時間
差し戻しが来たときの対応
承認されたらSVNで初回リリース
次のバージョンをリリースするとき
翻訳を自分で承認したい場合
提出前チェックリスト
参考リンク集
関連記事
まとめ

WordPress.orgにプラグインを提出して一発で通すのは難しい。でも、落ちる原因は決まっています。

私がRapls PDF Image Creatorを初めて提出したときは、エスケープ不足やプレフィックスの問題で差し戻されました。正直「ちゃんと動くのに何がダメなの？」と思いましたが、審査は「動くかどうか」ではなくセキュリティとガイドラインの準拠を見ています。

この記事では、提出準備から差し戻し対応、承認後のSVN公開までを一本の記事にまとめました。「これさえ読めば初提出でも慌てない」という内容を目指しています。

なお、私の審査体験の詳細は「WordPressプラグイン審査に通るまでの実体験」にまとめています。この記事はその経験を踏まえた「次に提出する人のための実践ガイド」です。

全体の流れを先に把握する

提出から公開までは「ZIP作成 → Plugin Check → 提出 → 差し戻し対応 → 承認 → SVN公開」の5ステップです。この順番で解説していきます。

① 提出用ZIPを作る
② Plugin Check + セルフチェックで不備を潰す
③ 提出フォームからZIPをアップロード
④ レビューチームから指摘が来たら修正して再提出
⑤ 承認後、SVNリポジトリに初回リリース

① 提出用ZIPを作る

② Plugin Check + セルフチェックで不備を潰す

③ 提出フォームからZIPをアップロード

④ レビューチームから指摘が来たら修正して再提出

⑤ 承認後、SVNリポジトリに初回リリース

この記事は①〜⑤の順番で解説していきます。

提出前に必ずやること（ここで9割決まる）

差し戻しの大半は提出前に防げます。「出してから直す」と審査の待ち時間（1〜10営業日）が往復するたびにかかるので、事前準備に時間をかけたほうが結果的に早いです。

公式ガイドラインにざっと目を通す

最低限、以下の3つは提出前に読んでおいてください。全文を精読する必要はありませんが、「どういう項目がチェックされるのか」の大枠を掴んでおくだけで差し戻しが大幅に減ります。

Detailed Plugin Guidelines——審査の詳細ガイドライン（全18項目）
Plugin Security——セキュリティ要件（差し戻し最多のカテゴリ）
How Your readme.txt Works——readme.txtの書き方

WordPress.orgアカウントと2FAの準備

2025年現在、プラグイン提出には2FA（2段階認証）が必須です。設定していないと提出ボタンを押しても先に進めません。

https://login.wordpress.org/register でアカウントを作成
ログイン後、右上のアバター → Edit Profile → Security タブ
Two-Factor Authenticationで認証アプリ（Google Authenticator等）を設定
復旧コード（Backup Codes）を安全な場所に保管

ユーザー名は後から変更できません。readme.txtのContributorsに記載する名前になるので、慎重に決めてください。

プラグインヘッダーを整える

レビュー担当が最初に見るのがメインPHPファイルのヘッダーです。ここが雑だと印象が悪くなります。

以下の雛形をベースに、自分のプラグインに合わせて書き換えてください。

<?php
/**
 * Plugin Name:       Your Plugin Name
 * Plugin URI:        https://example.com/your-plugin
 * Description:       A brief description in English (recommended ~140 characters).
 * Version:           1.0.0
 * Requires at least: 6.0
 * Requires PHP:      7.4
 * Author:            Your Name
 * Author URI:        https://example.com
 * License:           GPLv2 or later
 * License URI:       https://www.gnu.org/licenses/gpl-2.0.html
 * Text Domain:       your-plugin-slug
 * Domain Path:       /languages
 */

if ( ! defined( 'ABSPATH' ) ) {
    exit;
}

<?php

/**

* Plugin Name: Your Plugin Name

* Plugin URI: https://example.com/your-plugin

* Description: A brief description in English (recommended ~140 characters).

* Version: 1.0.0

* Requires at least: 6.0

* Requires PHP: 7.4

* Author: Your Name

* Author URI: https://example.com

* License: GPLv2 or later

* License URI: https://www.gnu.org/licenses/gpl-2.0.html

* Text Domain: your-plugin-slug

* Domain Path: /languages

if ( ! defined( 'ABSPATH' ) ) {

exit;

}

ここで差し戻されやすいポイントを先に潰しておきます。

Descriptionは英語で書く。readme.txt・ヘッダー・申請フォームはすべて英語が必要です。日本語での説明は公開後の翻訳システムで対応します。

Versionとreadme.txtのStable tagを完全に一致させる。「1.0」と「1.0.0」の違いでも差し戻されます。

Text Domainはフォルダ名（slug）と一致させる。プラグインのディレクトリ名がmy-pluginなら、Text Domainもmy-pluginです。

直接アクセス防止（defined('ABSPATH')）を全PHPファイルに入れる。メインファイルだけでなく、includesの中のファイルにも必要です。

同梱するすべてのファイルがGPL互換ライセンスか確認する。JavaScriptやCSS、画像、フォントも含めてです。「フリー素材だから大丈夫」と思っていても、商用利用不可や再配布不可のライセンスの場合があります。

readme.txtを作成する

readme.txtはプラグインページの元データになる重要ファイルです。レビューで必ず確認され、公開後はプラグインの説明文・FAQ・更新履歴のベースになります。

雛形（コピペして使ってください）

=== Your Plugin Name ===
Contributors: yourwporgusername
Donate link: https://example.com/donate
Tags: utility, admin, tool
Requires at least: 6.0
Tested up to: 6.7
Stable tag: 1.0.0
Requires PHP: 7.4
License: GPLv2 or later
License URI: https://www.gnu.org/licenses/gpl-2.0.html

A short description of your plugin in one line (max 150 characters, no markup).

== Description ==

Write a detailed description of your plugin here.

**Key Features:**

* Feature 1: Brief explanation
* Feature 2: Brief explanation

== Installation ==

1. Go to "Plugins" → "Add New"
2. Search for "Your Plugin Name"
3. Click "Install Now" and then "Activate"

== Frequently Asked Questions ==

= Is this plugin free? =

Yes, this plugin is completely free and open source.

== Screenshots ==

1. Settings page - Configure the plugin options here
2. Frontend display - How it looks on your site

== Changelog ==

= 1.0.0 =
* Initial release

== Upgrade Notice ==

= 1.0.0 =
Initial release of the plugin.

=== Your Plugin Name ===

Contributors: yourwporgusername

Donate link: https://example.com/donate

Tags: utility, admin, tool

Requires at least: 6.0

Tested up to: 6.7

Stable tag: 1.0.0

Requires PHP: 7.4

License: GPLv2 or later

License URI: https://www.gnu.org/licenses/gpl-2.0.html

A short description of your plugin in one line (max 150 characters, no markup).

== Description ==

Write a detailed description of your plugin here.

**Key Features:**

* Feature 1: Brief explanation

* Feature 2: Brief explanation

== Installation ==

1. Go to "Plugins" → "Add New"

2. Search for "Your Plugin Name"

3. Click "Install Now" and then "Activate"

== Frequently Asked Questions ==

= Is this plugin free? =

Yes, this plugin is completely free and open source.

== Screenshots ==

1. Settings page - Configure the plugin options here

2. Frontend display - How it looks on your site

== Changelog ==

= 1.0.0 =

* Initial release

== Upgrade Notice ==

= 1.0.0 =

Initial release of the plugin.

readme.txtで差し戻されやすいポイント

Contributorsには WordPress.orgのユーザー名を書く。任意の名前ではありません。ここを間違えるとプラグインページの作者リンクが壊れます。

Stable tagはPHPヘッダーのVersionと完全一致させる。繰り返しになりますが、これは差し戻しの常連です。

Tested up toは実際にテストしたバージョンを書く。未検証のバージョンを書いて「最新対応してます」と見せるのはやめましょう。

Stable tag: trunkは使わない。trunkを指定すると作業途中のコードがユーザーに配布されるリスクがあります。素直にバージョン番号を書いてください。

Readme Validatorで検証する

作成したらReadme Validatorで必ずチェックしてください。readme.txtの内容を貼り付けて「Validate」を押すだけです。エラーが出たら修正します。

▲ Readme Validatorの実行結果

英語が苦手な場合

完璧な英語である必要はありません。審査チームは世界中の非ネイティブからの申請に慣れています。まず日本語で書いてからDeepLやChatGPTで翻訳し、似た機能のプラグインのreadme.txtを参考に表現を整えるのが現実的です。

Plugin Checkで検査する——提出前の最重要タスク

Plugin Checkに通らないプラグインは、提出しても自動でブロックされます。ここをスキップすると時間の無駄になります。

Plugin Check（PCP）はWordPress.org公式の検査ツールで、提出時に行われるチェックの大部分を事前に実行できます。

インストールと使い方

WordPress管理画面 → プラグイン → 新規追加 →「Plugin Check」で検索
Plugin Check (PCP) をインストール → 有効化
管理画面 → ツール → Plugin Check
チェックしたいプラグインを選択し、カテゴリで「Plugin repo」を選択
「チェックを実行」をクリック

▲ Plugin Checkの実行画面

結果の読み方

ERROR（赤）は必ずゼロにしてください。ERRORが残っていると提出自体がブロックされます。WARNING（黄）は可能な限り対応し、どうしても消せないものは理由を説明できる状態にしておきます。INFO（青）は余裕があれば。

よく出る指摘と修正方法

私の経験上、指摘の大半は以下の5パターンに集約されます。

① エスケープ不足（最も多い）

// NG: エスケープなし
echo $user_input;
echo $url;

// OK: 適切なエスケープ関数を使用
echo esc_html( $user_input );
echo esc_url( $url );
echo '<input value="' . esc_attr( $value ) . '">';

// NG: エスケープなし

echo $user_input;

echo $url;

// OK: 適切なエスケープ関数を使用

echo esc_html( $user_input );

echo esc_url( $url );

echo '<input value="' . esc_attr( $value ) . '">';

HTMLに出力する文字列にはesc_html()、URLにはesc_url()、HTML属性値にはesc_attr()。これを全出力箇所に入れます。「自分で作ったデータだからエスケープ不要」は通用しません。

② サニタイズ不足

// NG: サニタイズなし
$value = $_POST['value'];

// OK: サニタイズあり
$value = sanitize_text_field( wp_unslash( $_POST['value'] ) );
$email = sanitize_email( $_POST['email'] );
$number = absint( $_POST['number'] );

// NG: サニタイズなし

$value = $_POST['value'];

// OK: サニタイズあり

$value = sanitize_text_field( wp_unslash( $_POST['value'] ) );

$email = sanitize_email( $_POST['email'] );

$number = absint( $_POST['number'] );

$_POSTや$_GETから受け取った値は、用途に応じたsanitize関数を通してから使います。

③ Nonceと権限チェックの不足

// NG: 検証なしで保存
if ( isset( $_POST['save'] ) ) {
    update_option( 'my_option', $_POST['value'] );
}

// OK: Nonce + 権限チェックあり
if ( isset( $_POST['save'] ) ) {
    if ( ! isset( $_POST['_wpnonce'] ) || 
         ! wp_verify_nonce( $_POST['_wpnonce'], 'my_save_action' ) ) {
        wp_die( 'Security check failed' );
    }
    if ( ! current_user_can( 'manage_options' ) ) {
        wp_die( 'Permission denied' );
    }
    update_option( 'my_option', sanitize_text_field( $_POST['value'] ) );
}

// NG: 検証なしで保存

if ( isset( $_POST['save'] ) ) {

update_option( 'my_option', $_POST['value'] );

}

// OK: Nonce + 権限チェックあり

if ( isset( $_POST['save'] ) ) {

if ( ! isset( $_POST['_wpnonce'] ) ||

! wp_verify_nonce( $_POST['_wpnonce'], 'my_save_action' ) ) {

wp_die( 'Security check failed' );

}

if ( ! current_user_can( 'manage_options' ) ) {

wp_die( 'Permission denied' );

}

update_option( 'my_option', sanitize_text_field( $_POST['value'] ) );

}

フォーム送信にはNonce検証（CSRF対策）と権限チェック（current_user_can）の両方が必要です。

④ 直接アクセス防止の不足

// すべてのPHPファイルの先頭に入れる
if ( ! defined( 'ABSPATH' ) ) {
    exit;
}

// すべてのPHPファイルの先頭に入れる

if ( ! defined( 'ABSPATH' ) ) {

exit;

}

⑤ プレフィックスの問題

// NG: プレフィックスが短い、汎用的すぎる
function wcp_init() {}
function init() {}

// OK: 4文字以上のユニークなプレフィックス
function your_plugin_init() {}
class Your_Plugin_Main {}

// NG: プレフィックスが短い、汎用的すぎる

function wcp_init() {}

function init() {}

// OK: 4文字以上のユニークなプレフィックス

function your_plugin_init() {}

class Your_Plugin_Main {}

関数名・クラス名・定数名にはプラグイン固有のプレフィックスを付けます。4文字未満や汎用的な名前（init、setup等）は指摘されます。

Plugin Checkには誤検知もあります。明らかにfalse positiveの場合は、レビュー担当に説明できる準備をしておけば問題ありません。

「Plugin repo」に加えて「Security」カテゴリも実行しておくと、セキュリティ上の問題を先に発見できます。

提出用ZIPを作成する

ZIPの構成ミスで差し戻されるのは最ももったいないパターンです。直下にプラグインフォルダが1つだけ入っている状態にし、不要ファイルを除外してから作成してください。

正しい構成

ZIPの直下にプラグインフォルダが1つだけ入っている状態にします。

your-plugin-slug.zip
└── your-plugin-slug/
    ├── your-plugin-slug.php    ← メインファイル
    ├── readme.txt              ← 必須
    ├── includes/
    ├── assets/
    │   ├── css/
    │   └── js/
    └── languages/

your-plugin-slug.zip

└── your-plugin-slug/

├── your-plugin-slug.php ← メインファイル

├── readme.txt ← 必須

├── includes/

├── assets/

│ ├── css/

│ └── js/

└── languages/

二重フォルダに注意。ZIPを解凍して「フォルダの中にフォルダ」になっていたらアウトです。作成後に別の場所で解凍して確認してください。

ZIPに含めないもの

.git/、node_modules/、vendor/（必要なものを除く）、tests/、.DS_Store、Thumbs.db、APIキーやパスワードを含むファイル——これらはすべて除外します。

# Mac / Linux でのZIP作成例
cd /path/to/plugins
zip -r your-plugin-slug.zip your-plugin-slug \
    -x "*.git*" "*.DS_Store" "*__MACOSX*" "*node_modules*"

# Mac / Linux でのZIP作成例

cd /path/to/plugins

zip -r your-plugin-slug.zip your-plugin-slug \

-x "*.git*" "*.DS_Store" "*__MACOSX*" "*node_modules*"

提出する

準備が整ったら提出ページからZIPをアップロードします。slugは承認後に変更できないので、スペルミスや商標侵害がないか提出前に必ず確認してください。

提出ページからZIPをアップロードします。

▲ 提出ページの画面

アップロードするとPlugin Checkが自動実行されます。ERRORがあれば提出がブロックされ、ERRORがなければ審査キューに入ります。

slugは一生変わらない——ここだけは慎重に

プラグインのslug（URLの一部）は、承認後に変更できません。

https://wordpress.org/plugins/your-plugin-slug/——このURLが永久に固定されます。スペルミス、他のプラグインとの名前被り、商標侵害がないか、提出前に必ず確認してください。

審査が始まる前であればslugを変更できる場合がありますが、始まってしまうと変更不可です。

審査の待ち時間

通常1〜10営業日です。混雑時は2週間以上かかることもあります。催促は逆効果になるので、2週間は待ちましょう。

差し戻しが来たときの対応

差し戻しメールが来たら、まず翻訳して指摘箇所を抜き出し、セキュリティ関連（Nonce・権限・エスケープ・サニタイズ）を最優先で修正してください。

審査で問題が見つかると、plugins@wordpress.orgから英語のメールが届きます。

▲ 差し戻しメールの画面

まず翻訳して要件を抜き出す

メールをDeepLやGoogle翻訳にかけて、指摘箇所（ファイル名・関数名・行番号）、問題の種類、修正の方向性を整理します。

複数の指摘がある場合は、セキュリティ関連（Nonce・権限チェック・エスケープ・サニタイズ）を最優先で修正してください。これがないと絶対に通りません。

修正したZIPの再提出方法

指摘を修正する
バージョンを上げる（例：1.0.0 → 1.0.1）。PHPヘッダーとreadme.txtの両方
Plugin Checkを再実行してERRORゼロを確認
新しいZIPを作成
提出ページで自分の申請を開き、新ZIPをアップロード
レビュー担当にメールで修正内容を連絡

古い記事では「メールにZIPを添付して返信」と書かれていることがありますが、現在は提出ページからの再アップロードが推奨です。

返信テンプレート

修正内容を箇条書きで伝えるのがポイントです。長文より、何を直したかがひと目でわかるメールのほうがスムーズに進みます。

Hi Plugin Review Team,

Thank you for your feedback.

I have addressed all the issues and uploaded the corrected ZIP (version 1.0.1) via the submission page.

Changes made:

1) Added esc_html() to all output in admin-page.php (lines 45, 67, 89)
2) Added nonce verification to the settings save function
3) Added current_user_can('manage_options') check before processing form data
4) Changed function prefix from "mp_" to "my_plugin_" throughout the plugin
5) Added sanitize_text_field() to all $_POST inputs

I have also re-run Plugin Check and confirmed there are no errors.

Please let me know if you need any additional changes.

Best regards,
[Your Name]

Hi Plugin Review Team,

Thank you for your feedback.

I have addressed all the issues and uploaded the corrected ZIP (version 1.0.1) via the submission page.

Changes made:

1) Added esc_html() to all output in admin-page.php (lines 45, 67, 89)

2) Added nonce verification to the settings save function

3) Added current_user_can('manage_options') check before processing form data

4) Changed function prefix from "mp_" to "my_plugin_" throughout the plugin

5) Added sanitize_text_field() to all $_POST inputs

I have also re-run Plugin Check and confirmed there are no errors.

Please let me know if you need any additional changes.

Best regards,

[Your Name]

指摘の意味がわからない場合は、メールに返信して質問して問題ありません。丁寧に聞けば教えてもらえます。英語が不安なら翻訳ツールを使えば十分通じます。

承認されたらSVNで初回リリース

承認メールに記載されたSVNリポジトリURLにcheckoutし、trunkにファイルを配置してcommit、tagsにバージョンをコピーすれば公開完了です。assetsの配置場所（trunk/assets/ではなくリポジトリ直下のassets/）だけは間違えないでください。

審査に通ると承認メールが届き、あなた専用のSVNリポジトリURLが案内されます。

▲ 承認メールの画面

WordPress.orgのSVNは「配布用リポジトリ」です。GitHubのように細かいcommitを積む場所ではなく、リリース単位でまとめてcommitするのがベストプラクティスです。（SVNの基本操作や詳しい運用については「WordPressプラグインを公開して学んだSVNの使い方」を参照してください。）

リポジトリの構造

your-plugin-slug/
├── trunk/       ← プラグインの最新コード
├── tags/        ← リリース済みバージョンのスナップショット
│   └── 1.0.0/
├── branches/    ← 通常は使わない
└── assets/      ← バナー・アイコン・スクリーンショット（※trunkの中ではない）

your-plugin-slug/

├── trunk/ ← プラグインの最新コード

├── tags/ ← リリース済みバージョンのスナップショット

│ └── 1.0.0/

├── branches/ ← 通常は使わない

└── assets/ ← バナー・アイコン・スクリーンショット（※trunkの中ではない）

初回リリースの手順

# ① リポジトリをチェックアウト
svn checkout https://plugins.svn.wordpress.org/your-plugin-slug/ wporg-svn
cd wporg-svn

# ② trunkにプラグインファイルを配置
cp -r /path/to/your-plugin/* trunk/
svn add trunk/* --force

# ③ assetsにバナー・アイコンを配置（※リポジトリ直下のassets/）
cp /path/to/banner-772x250.png assets/
cp /path/to/icon-256x256.png assets/
cp /path/to/screenshot-1.png assets/
svn add assets/* --force

# ④ コミット
svn ci -m "Initial release: version 1.0.0"

# ⑤ tagsにバージョンを固定
svn cp trunk tags/1.0.0
svn ci -m "Tag version 1.0.0"

# ① リポジトリをチェックアウト

svn checkout https://plugins.svn.wordpress.org/your-plugin-slug/ wporg-svn

cd wporg-svn

# ② trunkにプラグインファイルを配置

cp -r /path/to/your-plugin/* trunk/

svn add trunk/* --force

# ③ assetsにバナー・アイコンを配置（※リポジトリ直下のassets/）

cp /path/to/banner-772x250.png assets/

cp /path/to/icon-256x256.png assets/

cp /path/to/screenshot-1.png assets/

svn add assets/* --force

# ④ コミット

svn ci -m "Initial release: version 1.0.0"

# ⑤ tagsにバージョンを固定

svn cp trunk tags/1.0.0

svn ci -m "Tag version 1.0.0"

初回のcommitではWordPress.orgのユーザー名とパスワードを求められます。

assetsの配置場所だけは絶対に間違えないでください

バナーやアイコンはリポジトリ直下のassets/に置きます。trunk/assets/ではありません。私もここを間違えて半日悩みました。配置場所が違ってもエラーメッセージが出ないので、気づきにくいのが厄介です。

assetsのファイル名と画像サイズは以下の通りです。

種類	ファイル名	サイズ
バナー	banner-772×250.png	772×250px
バナー（Retina）	banner-1544×500.png	1544×500px
アイコン	icon-128×128.png	128×128px
アイコン（Retina）	icon-256×256.png	256×256px
スクリーンショット	screenshot-1.png, screenshot-2.png …	任意（横幅1200px程度推奨）

スクリーンショットの番号は、readme.txtの== Screenshots ==セクションの番号と対応させます。

▲ WordPress.orgのプラグインページ（バナーとアイコンが表示されている状態）

commitからプラグインページへの反映まで15分〜数時間かかることがあります。CDNキャッシュの影響なので、焦って何度もcommitしないでください。

次のバージョンをリリースするとき

trunkのファイルを更新してcommitし、tagsに新バージョンをコピーするだけです。PHPヘッダーのVersionとreadme.txtのStable tagの両方を新バージョンに更新するのを忘れずに。

初回公開後にバグ修正や機能追加でアップデートする手順です。

# 最新状態を取得
cd wporg-svn
svn up

# trunkのファイルを更新
cp -r /path/to/updated-plugin/* trunk/

# 削除されたファイルがあれば一括処理
svn status | grep '^!' | awk '{print $2}' | xargs svn delete

# コミット
svn ci -m "Update to version 1.0.1"

# tagsに新バージョンをコピー
svn cp trunk tags/1.0.1
svn ci -m "Tag version 1.0.1"

# 最新状態を取得

cd wporg-svn

svn up

# trunkのファイルを更新

cp -r /path/to/updated-plugin/* trunk/

# 削除されたファイルがあれば一括処理

svn status | grep '^!' | awk '{print $2}' | xargs svn delete

# コミット

svn ci -m "Update to version 1.0.1"

# tagsに新バージョンをコピー

svn cp trunk tags/1.0.1

svn ci -m "Tag version 1.0.1"

PHPヘッダーのVersionとreadme.txtのStable tagを新バージョンに更新するのを忘れずに。ここがズレていると、WordPress管理画面の「更新あり」通知が正しく動きません。

readme.txtの「Tested up to」だけ更新する場合（WordPressの新バージョンが出たときなど）は、trunkとtagsの両方のreadme.txtを直接編集してcommitするだけでOKです。

翻訳を自分で承認したい場合

プラグイン作者でも翻訳を自分で承認するにはPTE（Project Translation Editor）の権限が必要です。申請手順は別記事で解説しています。

公開後に日本語翻訳を追加する場合、translate.wordpress.orgで翻訳を投稿しても、デフォルトでは「承認待ち」のままです。プラグイン作者でも、翻訳を自分で承認するにはPTE（Project Translation Editor）の権限が必要です。

PTE申請の手順は「自作WordPressプラグインでPTEを取るまでの実体験」で解説しています。

提出前チェックリスト

以下のすべてにチェックが付いたら提出してください。アカウント・ヘッダー・readme.txt・Plugin Check・ZIPの5カテゴリで確認します。

【アカウント】
□ WordPress.orgアカウント作成済み
□ 2FA有効化済み
□ 復旧コードを安全に保管

【プラグインヘッダー】
□ 必須項目をすべて記載（英語で）
□ Text Domain = フォルダ名 = slug が一致
□ 全PHPファイルに直接アクセス防止を追加
□ 同梱物がすべてGPL互換ライセンス

【readme.txt】
□ 英語で記載、標準フォーマットに従っている
□ Readme Validatorでエラーゼロ
□ Stable tag = PHPヘッダーのVersion（完全一致）
□ Tested up toは実際にテストしたバージョン
□ ContributorsがWordPress.orgのユーザー名

【Plugin Check】
□ Plugin repoカテゴリのERRORがゼロ
□ （推奨）SecurityカテゴリもERRORゼロ

【ZIP】
□ 直下にプラグインフォルダが1つ（二重フォルダなし）
□ 不要ファイルを除外（.git, node_modules, .DS_Store等）
□ 機密情報が含まれていない

【アカウント】

□ WordPress.orgアカウント作成済み

□ 2FA有効化済み

□ 復旧コードを安全に保管

【プラグインヘッダー】

□ 必須項目をすべて記載（英語で）

□ Text Domain = フォルダ名 = slug が一致

□ 全PHPファイルに直接アクセス防止を追加

□ 同梱物がすべてGPL互換ライセンス

【readme.txt】

□ 英語で記載、標準フォーマットに従っている

□ Readme Validatorでエラーゼロ

□ Stable tag = PHPヘッダーのVersion（完全一致）

□ Tested up toは実際にテストしたバージョン

□ ContributorsがWordPress.orgのユーザー名

【Plugin Check】

□ Plugin repoカテゴリのERRORがゼロ

□ （推奨）SecurityカテゴリもERRORゼロ

【ZIP】

□ 直下にプラグインフォルダが1つ（二重フォルダなし）

□ 不要ファイルを除外（.git, node_modules, .DS_Store等）

□ 機密情報が含まれていない

参考リンク集

この記事で参照した公式ドキュメントの一覧です。

プラグイン開発に関連する実体験記事です。

まとめ

差し戻しの原因はほぼ決まっています。エスケープ不足、サニタイズ不足、Nonce未検証、権限チェック忘れ、バージョン番号の不一致——この5つを潰しておけば、大半の差し戻しは防げます。

承認後のSVN操作も、assetsの配置場所（trunk/assets/ではなくassets/）とStable tagの仕組みさえ理解すれば難しくありません。

最初の1回は大変ですが、一度公開してしまえばあとはSVNでアップデートするだけです。自分のプラグインが世界中のWordPressサイトで使われる体験は、開発者として格別です。

WordPress.orgのプラグイン審査に一発で通すための全手順｜提出準備から差し戻し対応、SVN公開まで