Unwanted WordPress accounts: close the correct registration routes

Verify that these are genuinely new accounts

Unknown addresses appear among your site’s users even though you thought registration was closed. The first goal is to identify the route still open, then verify it no longer permits unwanted creation. The second is to decide how to handle existing accounts, their content and any orders. Closing registration does not delete existing users.

This guide concerns self-hosted WordPress with administrator access to settings and the account list. In multisite, some decisions belong to the network super administrator. On WordPress.com, invitations and platform-account management use other screens; do not confuse a WordPress.com account with a user added to your independent installation.

Open Users, then All Users; menu wording may vary by translation. Search for two or three reported usernames and record their roles. A comment signed with an unknown name is not, by itself, a user account. Nor does a registration notification prove an account was created at the moment you read it: email may arrive late.

If Administrator appears on an account nobody recognizes, have the case examined as suspicious privileged access. The unknown-administrator guide takes priority. Closing public forms does not remove existing access and is insufficient to address an account able to modify the site.

Find the open route before choosing a correction

A site may have several registration routes. The native WordPress form, a store, membership system, external-service login or import can create users under their own conditions. Unchecking a box in General settings does not prohibit every possible creation by an administrator or integration.

Record public pages offering registration while logged out of administration. Also check forms embedded in a homepage, footer or membership window. Note their real addresses and producing components. Do not assume a store’s account page necessarily uses a standard English address.

Compare these observations with recent changes: installing a store, adding a members’ area, importing customers or enabling external login. These events are leads, not proof. A Customer role often suggests a store but does not demonstrate which form created the user; an integration may assign the same role.

Also decide what should remain possible. An editorial site may close all public registration while retaining manual collaborator additions. A store may refuse registration without purchase while preserving a customer journey. Writing this rule in one sentence avoids closing orders or login for already authorized people.

• Simple WordPress site: start with the native registration setting and default role.
• Existing store: separately check My Account, checkout and available deferred-creation options.
• Multisite network: have network policy checked, then added forms on each affected site.
• Another plugin’s form: use its own options after precisely identifying its source.

Approach 1: close native WordPress registration

This method applies when the native form is open but only selected collaborators should receive access. It requires no additional plugin. With an administrator account, open Settings, then General. Find Membership and the Anyone can register checkbox.

Note the initial state, uncheck the box and click Save Changes at the bottom. Then reload settings to verify retention. Change neither site addresses nor the administration address: they do not close registration and could create another access problem.

On a standard non-multisite installation, then open the native registration route in a logged-out private window. If the usual login page is directly accessible, its registration link should disappear and native registration requests should be refused when the option is disabled. A login tool’s custom URL may change the path; use the site’s actual route.

The expected result is closed native public registration with existing-user login still available. An authorized administrator can still add a collaborator under Users, Add New. This is normal and does not mean the checkbox was ignored.

To roll back if open registration is ultimately needed, reenable the box and save after selecting appropriate protection and role. Do not reopen it simply to verify old behavior on a site currently receiving spam. Reading the setting and checking closure while logged out suffice for this first approach.

Check the default role without changing every user

Under Settings, General, also examine New User Default Role. On an editorial site allowing simple registration, Subscriber usually represents very limited access. A default Administrator role would be incompatible with ordinary public registration. Choose the minimum role matching the actual need, then save.

This setting applies to creations that use it. It does not downgrade already registered users or guarantee the role assigned by every plugin. A store may create Customers through its own route. Therefore do not treat a default-role change as proof that existing suspicious accounts have become harmless.

If the value was unusually high without a known decision, preserve that finding and investigate who can modify settings. Check privileged accounts with the site owner. Restoring a cautious value corrects current configuration; it does not establish that all previous activity was legitimate.

Do not apply a collective role change to every user. Authors, shop managers and collaborators may have different responsibilities. For an authorized individual correction, open the identified account, record its role, select the one matching its task and update. Rollback means restoring the previously agreed role, not granting higher permissions to resolve login difficulty.

The expected result is an appropriate future role and an understood list of existing access. If the goal is complete closure of public registration, also keep registration unchecked: reducing permissions does not prevent creation of large numbers of unnecessary accounts.

Approach 2: close unrestricted WooCommerce registration

This approach concerns only a store already using WooCommerce. Automattic’s free plugin has its own customer settings; installing it on an editorial site to fix this problem is unnecessary. The procedure below was verified on a copy with WooCommerce 11.2.1. Other commerce plugins’ features must be examined separately.

Open WooCommerce, Settings, then Accounts & Privacy. Under account creation, find On “My account” page. If you do not want registration without purchase from this page, uncheck the option and save changes. Keep a note of its initial value.

Open the actual My Account page in a private window. The registration form provided by this setting should disappear while the login form remains available for existing customers. Do not delete the My Account page: it may also provide access to orders, downloads and existing customers’ information.

This option works independently of WordPress’s Anyone can register. Native closure alone therefore does not hide WooCommerce registration. Conversely, hiding the My Account form is not a universal prohibition on customer creation through checkout, an API, an import or a plugin. The check concerns this specific route.

If the form remains visible, check that WooCommerce actually produces it and another plugin or builder has not replaced it. Refresh that page’s cached copy according to the existing system. If creations continue despite a closed form, record new occurrences and investigate their route; do not conclude that an invisible form blocks every request.

The expected result is no unrestricted My Account registration, with functional customer login. To roll back, reenable only this option and save. Handling accounts already created remains separate: this box does not delete them.

Preserve purchases when the store creates accounts

On the same WooCommerce screen, distinguish logging into an existing account, guest checkout and creating a new account. Logging in during checkout does not by itself create a user. Disabling its invitation to reduce spam may merely inconvenience known customers without closing the right route.

Recent versions may offer creation During checkout and After checkout. Examine each option available in your version. If policy prohibits all new public customer registration, disable the relevant creation options and save. If you only want to prevent registration without purchase, do not automatically close a necessary customer journey: first verify which scenario is actually being exploited.

Also check guest checkout. If you remove every creation option while requiring an account to purchase, a new customer may have no usable route. Allow guest checkout only if it matches your products and policy; it is not a universal replacement for an account, particularly for purchases requiring one.

Subscriptions and restricted areas may add their own requirements. If a plugin displays a special creation option for subscribers, have its scope approved before closing it. Do not disable an already sold service to eliminate a registration wave. Start by closing the unnecessary public route while retaining existing contractual access.

Full checkout verification must occur in an isolated test environment with a separate database, real emails and integrations disabled and a payment method in test mode. On the live store, observe forms without placing a real order for this diagnosis. Rollback restores saved options; it requires neither restoring the entire database nor deleting orders.

Approach 3: check a multisite network’s policy

If My Sites provides access to network administration, native registration depends on network policy. A site administrator may lack the necessary setting. With the responsible super administrator, open My Sites, Network Admin, then Settings and Network Settings.

Under Registration Settings, find permission for new registrations. Core offers several policies: registration disabled, user-account creation, site creation by logged-in users or opening both accounts and sites. If no public registration is intended, choose disabled and save. Keep the initial value and have effects checked on sites using that availability.

Do not confuse this decision with allowing site administrators to add users. An administrative invitation and public registration are different routes. A user already in the network may also be added to another site; appearing in a local list does not necessarily establish new network-account creation.

The expected result is closure of the native public route according to the chosen policy. Check the network registration page in a logged-out session, then specific forms on affected sites. Store or membership plugins may still require their own settings.

To roll back, the network administrator restores the initial policy after checking site needs. Do not have a user deleted network-wide to remove them from one site: the scope could affect several spaces and their content. Handling an existing account requires a separate documented decision.

If accounts keep appearing after closure

Choose an observation period starting when settings were saved. Record only genuinely new accounts and roles using already available information. An unchanged list after closure is normal: previous accounts do not disappear. A notification received after your intervention may also concern an earlier creation.

If hosting access logs are available, request queries around a few specific creations: time, path and request method. Supply the affected site address and closed settings. Avoid sending complete logs containing cookies or tokens. These details distinguish public registration, integration, administrative addition and a third-party form.

For an identified membership form, open its settings and find its own public-registration permission. Use documentation for its version before changing an option. No universal menu applies to every such plugin. Do not globally disable a store, members’ area or collaborator login on the live site for a test.

A comment antispam tool does not close account creation. Protection of native login does not automatically cover every custom form. If registration must remain open, choose protection compatible with the exact form and check that a legitimate reader can still use it. Adding protection in the wrong place does not fix the route actually exploited.

Separate account cleanup from final verification

Before deleting a suspicious account, check its content, orders and related communications. An unusual name or lack of published posts does not prove it is useless: a customer may have written no content. Keep the evidence needed for the decision with the site administrator and prepare an appropriate backup before deletion.

Avoid bulk deletion based solely on Subscriber or Customer roles. On a network, also check other memberships. If an account has unusually high permissions, first address its access and the cause of assignment through the appropriate security procedure. Closing public registration is a configuration measure; it does not replace that investigation.

Finish with three concrete findings: the correct option is saved, the targeted public form no longer offers unwanted creation and existing users retain expected login. For a store, also validate the customer journey in the isolated environment before retaining a change affecting checkout.

Keep a note of intentionally open routes and their owners. Repeat this check when adding a members’ area, store or external login. The site remains easier to control when every account creation corresponds to a known route rather than an assumption about a single WordPress checkbox.

Compare settings before and after closure

If you already have WP-CLI, run these reads from the WordPress copy’s directory. The first two show native public-registration status and default role. The third applies to a store with WooCommerce installed.

On our copy, the first command displayed 1 when the native route was open. The chosen role was subscriber. WooCommerce returned yes for My Account registration, then the setting became no when closed. Always check the visitor-side result. A saved value may coexist with another form supplied by a different component.

Check both routes separately on your WordPress and WooCommerce copy. First close native registration and check whether WooCommerce registration remains available. Then close the relevant WooCommerce option and verify that its registration form disappears while an existing fictional account can still log in. Restore initial values only on the copy to test rollback. Payment and network settings require their own checks.

wp option get users_can_register
wp option get default_role
wp option get woocommerce_enable_myaccount_registration

Read recent creations without exporting users’ contact details

A maintainer who already has WP-CLI can supplement form checks with a limited record of recent accounts. On the copy, adapt the path and address before running this read:

Compare IDs and dates between two records around the test without sharing email addresses. This command neither disables nor deletes accounts. In multisite, the target address determines the site queried, and the network account’s creation date does not necessarily represent its addition to that subsite. This record does not reveal the responsible form or integration either: compare it with the test and authorized logs. A new identity created by an approved integration must be distinguished from persistent public registration.

wp --path="/chemin/copie-wordpress" --url="https://copie.example.test" user list --orderby=registered --order=DESC --number=10 --fields=ID,user_registered,roles --format=table