Handle site access safely

A request for WordPress access often arrives as a one-line email: “Can you add our new contractor?” The WebMaster still has to work out who approved it, which site the person needs, what they must change, and when the access should end.

A WordPress access request form can collect those facts before anyone creates an account. It should never collect a password. Its job is to prepare a checkable request that names the authorization, the smallest useful role, the scope of work, and the person who owns the final decision.

Start with the access decision

“Needs access” is not a decision. Decide what the request is asking an authorized site owner or administrator to approve:

• a new WordPress user account;
• a role change for an existing user;
• temporary access for a defined project;
• access to a separate service connected to the site;
• an extension, revocation, or ownership change.

Keep those request types separate. A new editor account needs different evidence from a plugin administrator request or a handoff after an employee leaves.

Collect authorization, not credentials

The form should identify the requester, the intended user, the business owner who approved the request, and the reason access is needed. It should not ask for an existing password, a one-time code, an API key, a private key, or a recovery code.

WordPress can generate a strong password when an account is created. The official WordPress password guidance also recommends unique passwords and explains how password managers help people avoid reuse. Keep the access request focused on authorization. Handle account setup and credential delivery through the site’s approved process after the request is approved.

A form can record who asked for access. It should not become a place where people paste the keys.

Ask for the smallest useful role

Do not make the requester choose “Administrator” because it sounds like the fastest option. Ask what work the person must perform: edit existing pages, publish posts, upload media, manage users, install plugins, change settings, or only review private content.

The WordPress roles and capabilities guide explains the default permissions behind Administrator, Editor, Author, Contributor, and Subscriber. An authorized administrator should map the requested tasks to the right role. If the required work cannot be described, the request is not ready for approval.

Some plugins add their own roles and capabilities. Record the named task and site area rather than assuming a default role covers it. That gives the reviewer enough context to check the installed site before approving access.

Bound the site, scope, and time

An agency may manage dozens of sites. A contractor working on one landing page does not automatically need access to the network, hosting account, analytics, DNS, billing, and every client site.

• Name the exact site or environment.
• Describe the task and the content or settings it affects.
• State whether production access is required.
• Name the approving owner.
• Set a review or expiration date for temporary work.
• Record who will confirm the work is complete.

Use conditional questions so a content editor does not have to answer hosting questions. The W3C forms tutorial recommends asking only for information needed to complete the process and giving people clear labels and instructions.

Build a checkable access brief

A busy WebMaster should not have to reread several paragraphs to find the decision facts. An Entry Summary can put the request into a predictable brief:

• Requester: who submitted the form and which organization they represent;
• Intended user: who will receive access;
• Authorized owner: who can approve the request;
• Task: what the user needs to do;
• Scope: site, environment, and affected area;
• Time: start, review, and expiration dates;
• Unknowns: missing or conflicting facts that still need a person.

Keep the original submission available. The brief is a review aid, not a replacement for the record. Names, dates, roles, and site identifiers should remain checkable before someone creates or changes an account.

Flag only decision-blocking gaps

A blank optional note is not the same as a missing approver. A Missing Information Review can compare the request with a short access checklist and name only the gaps that block a safe decision.

• No authorized owner is named.
• The intended user is unclear.
• The requested work does not match the requested role.
• The site or environment is missing.
• Temporary access has no review date.
• The request contains a credential that should be removed from the intake record.

Ask for a reason beside each flag. If the model cannot point to the submitted facts or the checklist, the reviewer should ignore the suggestion.

Route the request without approving it

A Routing Recommendation can suggest whether the first review belongs to a client owner, content lead, developer, security contact, or hosting administrator. Routing is not approval. The named owner still has to confirm authorization, role, scope, and timing.

Use a separate status for requests that contain secrets. Do not repeat the secret in a summary, notification, or reply. Follow the site’s incident process to remove unnecessary copies and tell the requester how to use the approved credential channel.

When access is no longer needed, use the client form offboarding checklist to review accounts, integrations, destinations, and ownership instead of relying on memory.

Test common access scenarios

Before using the workflow, test it with synthetic requests that cover the cases your team sees:

1. an editor who needs to update existing pages for two weeks;
2. a developer who needs staging access but not production access;
3. a vendor request with no named client approver;
4. an Administrator request whose described task only needs editing rights;
5. a request that incorrectly includes a password or recovery code;
6. an extension request for an account that should have expired.

Write the expected owner, missing facts, and next step before running the actions. Compare every brief with the original submission. Add a regression example whenever the workflow hides a missing approver, recommends too much access, or repeats a secret.

Measure the review work

Do not score the workflow by how polished the brief sounds. Track operational outcomes:

• requests returned for a missing approver or unclear task;
• Administrator requests changed to a narrower role;
• temporary accounts reviewed on time;
• requests reassigned because the first owner was wrong;
• credentials caught and removed from the intake path;
• time from submission to an authorized decision.

The useful workflow makes the decision safer and easier to check. It does not turn access approval into an automatic model output.

Start with one request type

Begin with temporary WordPress editor access for one client or team. Define the approver, role, site scope, required dates, and credential boundary. Test the brief and missing-information rules with known examples before adding hosting, analytics, DNS, or other systems.