Strategy · November 6, 2026 · 8 min read
What Site Access to Ask a Client For Before You Start
Ask for a publishing role, not admin: a WordPress Editor with an application password, scoped staff access on Shopify, Wix, Webflow or Ghost, plus full-user Search Console and GA4 Viewer.
By FluxWriter
What website access do I need to start SEO is a question most agencies answer in one word: admin. That answer is why onboarding stalls, why the client's developer goes quiet, and why you end an engagement holding credentials you never needed. Publishing content takes one scoped role on the CMS and two low-privilege grants on the measurement side, and none of them is administrator. This post gives the least-privilege ask for each platform, how to move credentials without emailing them, and what to send when the developer will not reply.
The Default Ask Is Admin and It Costs You Two Weeks
Ask for administrator access and you have turned a content project into a security review. The person who approves it is rarely the person who hired you. It is a developer with a backlog, an IT contractor on retainer, or the founder's cousin who built the site in 2019. Admin means plugin installs, theme edits, user management and, on ecommerce, customer records. Granting that is a decision someone has to think about. Granting a role that publishes blog posts is not.
The delay is the real cost. As a rough rule, a first publish that waits on full admin slips one to three weeks, against two or three days for a scoped role. On an eight-post-a-month retainer, two weeks is four posts, half the month's deliverable gone before a word is written. You still invoice for month one, and the client still judges month three on what shipped.
Admin credentials you never needed are also credentials you have to account for when the work ends.
WordPress Publishing Needs an Editor Role and an Application Password
WordPress ships with five roles, and Editor is the one you want. An Editor can write, edit, publish and delete any post on the site, manage categories and tags, and moderate comments. An Editor cannot install plugins, edit theme files, change site settings, or create users. That is almost exactly the boundary a client wants and does not know exists.
If you publish by hand, that role is enough on its own. If anything you use publishes over the REST API, whether a tool, a script or a scheduler, ask for an application password too. Application passwords have been part of WordPress core since version 5.6. They are generated on a user's own profile screen, they authenticate API requests without exposing the account password, and each one can be revoked on its own.
The detail that matters is that an application password inherits the permissions of the user it belongs to. Generate it on the Editor account rather than the owner's, and the API can do exactly what that Editor can do and nothing more. An application password on an administrator account is an administrator credential, however it was labelled.
Two things break this. Some managed hosts and security plugins switch application passwords off, and WordPress disables them on sites not served over HTTPS unless a developer has overridden it. Confirm both before promising a publishing date.
Every Other CMS Hides Publishing Behind a Different Seat
Shopify keeps blog articles under Online Store, so the staff permission you want is the one covering blog posts and pages, not orders or customers. Agencies registered as Shopify Partners can often request collaborator access instead, which avoids consuming a staff seat.
Wix separates writing from publishing in its blog roles, so the two are different grants. Webflow's seat model has been reorganised more than once, and the ask there is content access to the CMS rather than a Designer seat. Ghost has staff roles and, separately, integrations that issue an Admin API key for automation. An administrator creates that key once, which is one admin action by the client rather than an admin seat for you.
Role names and plan limits move between versions and pricing tiers, so treat the table below as the request to open with, then confirm the exact label inside the client's own account.
| Platform | Least-privilege ask | Publishes posts | Stays out of reach |
|---|---|---|---|
| WordPress | Editor role, plus an application password on that same account for API publishing | Yes | Plugins, themes, site settings, users |
| Shopify | Staff or Partner collaborator access scoped to Online Store blog posts and pages | Yes | Orders, customers, finances, app installs |
| Wix | The blog role that includes publishing, rather than co-owner | Yes | Billing, domains, site design |
| Webflow | Content access to the CMS collections, rather than a Designer seat | Yes | Design, site settings, hosting |
| Ghost | Editor staff role, or a custom integration Admin API key for automation | Yes | Billing, themes, member data |
Search Console and Analytics Are Two Separate Grants, and Neither Needs Admin
Search Console permissions are set per property, in three levels: owner, full user and restricted user. Full user sees every report and can use most tools but cannot add or remove other users. That is the level to ask for. Ask for owner only when you are the one verifying a new property.
The verification method is the trap. A property verified by a tag, a DNS record or an HTML file stays verified only while that thing exists, so removing a tag manager container at the end of a contract can strip verification from someone who still needs it. Ask which method verified it before you change anything near it.
GA4 is a separate grant on a separate screen, with its own hierarchy of account, property and data stream. Viewer is enough to read reports, and Analyst adds saved explorations, which most organic reporting eventually wants. Editor and Administrator are not needed to read anything. Analytics also allows cost and revenue metrics to be restricted, which lets a cautious ecommerce client hold back margin data without blocking organic reporting.
Ask for both in one message, because a client who grants one very often believes they granted both.
Credentials Travel Through the Invite Flow, Never Through Email
Every platform here has an invitation flow, and that flow is the only acceptable route. The invitation goes to your own work email, you set your own credentials, and your actions land in the audit log under your name. You never receive a password.
A shared login breaks three things at once. Attribution goes first: when a post vanishes, nobody can say who removed it. Revocation goes next, because cutting your access means changing a password other contractors also use. Multi-factor authentication goes last, since a code landing on someone else's phone tends to get switched off entirely.
Some credentials are not accounts and cannot be invited. An application password, a Ghost Admin API key or a Webflow token has to be transmitted somehow. Use the client's password manager when they have one, a one-time link that expires after a single view when they do not. Not email, not Slack, not a shared document. A key pasted into a thread lives there for the life of the mailbox.
Whether a shared login breaches anything the client has agreed to is not your call. The question to put to them is what their own platform terms and contracts say. What you can state plainly is that you will not work from one.
A Silent Developer Needs a Three-Part Message, Not a Chase
The developer who will not reply is not ignoring you. They are triaging. Your request is an unquantified risk from a stranger, sitting under a checkout bug and a failing build. A follow-up asking for an update changes none of that.
Three parts change it. First, name the exact role and the exact screen, so the work takes under two minutes. "Users, Add New, role Editor, invite to this address" is a different request from "we need access to the site". Second, state what the role cannot do, in their language: it cannot install plugins, edit theme files, change settings or add users. That answers the objection holding up approval before it is raised.
Third, give a date and a named fallback with its cost attached. If this is not set up by Thursday, say, you will deliver formatted drafts by email instead, which works, but moves publishing onto their team and adds roughly a day to each post's turnaround. The developer is now choosing between two minutes of work and a recurring task landing on someone they sit next to.
Send it to the client and the developer on one thread, so whoever signed the contract sees the trade-off rather than hearing about it in month two.
FAQ
Can I just use the client's login if they offer it?
Decline it and ask for your own seat. A shared login destroys attribution, makes revocation messy for everyone using it, and usually means multi-factor authentication gets weakened to keep the sharing workable. Whether it also breaches terms the client has accepted is a question for them to check, not for you to rule on.
What if the client's plan does not have a spare seat?
On platforms that cap staff accounts by plan, the seat is a billing question before it is a permissions question. Three routes usually exist: partner or collaborator access that consumes no seat, a draft-only workflow where the client presses publish, or an upgrade they pay for. Price the draft-only route honestly, since it adds a handoff to every post.
Who should own the Search Console property?
Settle it in writing before anyone verifies anything, because ownership follows the verification method and outlasts the contract. The arrangement that usually holds up is the client owning the property while you hold full-user access, so nothing breaks when the engagement ends. If you verify it yourself to get started, agree up front how ownership moves later.
The Practical Takeaway
This week, stop asking for admin and start asking for a named role. Write one access request per platform you work on, naming the role, the screen it is granted from, what that role cannot do, and a date with a fallback. Send it with the contract rather than after it, put the Search Console and GA4 asks in the same message, and check API credentials are enabled before you commit to a publishing date. First action: write the WordPress version of that request today, because it is the one you will send most often.
When the access is for FluxWriter rather than a person, the WordPress request is the same Editor role and application password, and on Shopify it is a custom app the client creates in their own admin, with a token scoped to blog write access.