Simple SEO Noindex Toggle

It can stop excluding a page, which is not quite the same thing. Removing the noindex flag means this plugin no longer asks search engines to skip the page — but indexing is still Google's decision, and other factors on your site may keep the page out. The green "Indexed" badge means "no noindex flag from this plugin," not a guarantee the page sits in Google's index. Use URL Inspection in Search Console for a definitive answer.

There is no universal answer, but some common patterns hold. Single-author blogs almost always benefit from noindexing author archives, since that page duplicates the main blog listing. Date archives are rarely useful to anyone and are safe to exclude on most sites. Paginated pages are a reasonable default to enable. Category and tag archives need more thought. If your categories carry written descriptions and pull in search traffic, leave them indexed. If they exist purely to organise the admin side, exclude them. Check your Search Console performance report before deciding — if an archive is already earning clicks, leave it alone.

Because the two directives answer different questions. noindex says "do not list this page in results." nofollow says "do not follow the links on this page." On an archive, the links are the whole point — they lead to the posts you do want indexed. Adding nofollow would tell search engines to stop crawling through to your own content, which is almost never what anyone wants.

This is nearly always caching. The verifier sends a fresh request with a cache-busting query string and no-cache headers, but some caching plugins and CDNs will still serve a stored copy. Purge your cache and verify again. If it still fails, check the page source manually using Method 2.

The verifier uses wp_remote_get(), which asks your server to make an HTTP request back to itself. Some local development environments and locked-down hosts block this. The plugin still works correctly in these cases — only the verifier is unavailable. Use Method 2 to check the source directly.

For archive pages, no. The archive feature filters WordPress core's robots tag rather than printing its own, so directives merge cleanly. For individual posts, the per-post toggle writes its own tag into wp_head. If another SEO plugin also outputs a robots tag for that post, both will appear in the source. Search engines honour the most restrictive instruction, so the result is still correct — it just looks untidy. To keep things clean, use one plugin's noindex feature per post rather than both.

Not yet. Posts and Pages are supported. Custom post type support is planned for a future release.

It can, which is why every archive option ships turned off and requires you to enable it deliberately. Before switching one on, open Search Console and check whether that archive type is receiving impressions or clicks. If it is, leave it indexed. Noindex is quick to apply and slow to undo — recovering a deindexed page can take weeks.

No. Settings live in wp_options and per-post flags in wp_postmeta, both WordPress core tables.

The uninstall.php routine removes all plugin settings (ssnit_settings from wp_options) and all per-post noindex flags (_ssnit_noindex from wp_postmeta). No orphaned data remains, and the routine is multisite-aware. Worth noting: deleting the plugin removes the noindex tags too, so any page you had excluded becomes eligible for indexing again.

Yes. The meta box renders in the block editor sidebar, and every feature behaves identically in both the block editor and Classic Editor.

Yes. Quick Edit submits through WordPress's own AJAX handler, and the checkbox is processed via the standard save_post hook — no custom endpoint involved.

Yes. Each subsite keeps its own independent settings, and the uninstall routine cleans up every subsite.

No. Nothing is enqueued on the frontend. Singular pages incur one get_post_meta() call, and archive pages a single options lookup that WordPress has already cached.