WordPress outsourcing for SEO agencies: how to retain a developer on a monthly contract

An SEO agency sells audits, content strategy and link building. After the audit you are left with a list of fixes, and a good share of them need changes to the theme, the plugins or the server configuration. With no WordPress developer on the team that list sits untouched, and by July the client is asking why the March report still has not changed anything. This guide explains how to hand that work to an outside developer on a monthly retainer: what to give them, how to grant access without handing over accounts, what goes into the contract under UK and Irish law, and how to check whether the work is paying off.

The sections on copyright and data protection summarise the law as it stood on 24 October 2026, for agencies in the United Kingdom and Ireland. They are not legal advice for your agency, and the sample clauses below are drafts for your solicitor to review, not finished contract wording.

#In short

• The agency keeps diagnosis, priorities and the client relationship. The developer owns implementation and makes sure a change does not break production.
• You grant access to a person, not a company: a separate Search Console user, a separate WordPress account, a separate SSH key. Each one can be revoked in a single step.
• The contract sets a monthly cap on hours, a first response time (separate from the fix time), how larger work is quoted, white-label terms and confidentiality.
• Code written by an outside developer belongs to them until they assign it in a signed document. In the UK and in Ireland the employer rule does not reach contractors.
• A developer with access to sites holding personal data is a sub-processor, so you need the client’s written authorisation and a processing agreement with the developer.
• You measure each task: the state before, the release date, and the state after 28 days of CrUX or Search Console data.

#Glossary for agency owners

#Which SEO audit tasks need a WordPress developer

A technical audit usually ends with a list of findings, not a list of names. The first step is deciding who does what. The split below follows where the change lives: in content and admin settings, or in code and on the server.

When you send the developer a ticket, the “SEO agency” column tells you what they expect from you: a URL list, Search Console data, a redirect map. A ticket without that data starts with questions, and questions eat hours from the package. We look at where the weeks of waiting for simple changes come from in why WordPress changes take weeks.

#What a ready ticket looks like

A ticket the developer can start on without a reply contains five things: the expected result, the URLs, the environment (staging or production), the data needed to reproduce the problem, and an acceptance criterion. For a redirect task after a migration that means the spreadsheet of old and new URLs, a note on whether query strings must be preserved, the date the old URLs dropped out of the sitemap, and the test that closes the ticket (“every URL in column A returns a single 301 to column B”). For a performance ticket it means the template, three example URLs, the mobile LCP p75 from Search Console and the element Lighthouse names as the LCP element. Writing this takes ten minutes. A missing piece costs a round of email, and with a developer on CET hours a round of email can cost a working day.

#How to give a developer Search Console access without sharing your account

Search Console has five permission levels. The descriptions below come from Google’s documentation on users and permissions (support.google.com).

A developer almost never needs ownership. Full user access covers the job: they see every report, while adding users and changing settings stay with the owners.

Tokens are the part people miss when a contract ends. According to the same Google page, a removed owner loses access, but their verification tokens are not removed or invalidated. If a token (an HTML file, a meta tag, a DNS record) is still on the site or in the domain, that person can verify the property again. So an outside developer should never verify the property with their own account. If they once did, you remove both the user and the token when you part ways. Google flags this in the interface: if the removal dialog says the user may regain access, their tokens are still in place.

If every verified owner is removed, the remaining users and delegated owners lose access after a grace period. The client should therefore be the verified owner, while the agency and the developer work through access the client can control.

#Which WordPress role to give an external developer

WordPress ships six default roles. The documentation on wordpress.org describes them as follows: Super Admin manages a multisite network, Administrator has access to all administration features of a single site, Editor publishes and manages posts including other people’s, Author publishes their own posts, Contributor writes but cannot publish, and Subscriber can only manage their own profile.

On a single site only the Administrator holds, among others, these capabilities: update_core, update_plugins, install_plugins, edit_plugins, edit_themes, edit_files, create_users, delete_users and unfiltered_html. On multisite only the Super Admin has them. A developer who is meant to update or install plugins therefore needs the Administrator role on staging and usually on production too. The Editor role is not enough for technical work.

Since the developer’s account is an administrator account, the hygiene around it matters:

• A separate account for each person. One shared “agency-dev” login means you cannot tell who changed what, and you cannot remove one person without changing everyone’s password.
• File editing disabled in the dashboard. WordPress hardening documentation (developer.wordpress.org) states that define( 'DISALLOW_FILE_EDIT', true ); in wp-config.php is equivalent to removing edit_themes, edit_plugins and edit_files from every user. The developer should be shipping code from a repository anyway, not through the dashboard editor.
• Staging with the environment declared. The wp_get_environment_type() function returns local, development, staging or production, and falls back to production when nothing is set (developer.wordpress.org). Setting staging on the copy lets code and plugins behave differently there, for example by not emailing the shop’s customers.
• SFTP or SSH instead of FTP. The same hardening documentation recommends SFTP because the password and data are encrypted in transit. In practice a separate SSH key per person works better: revoking access means deleting one line from authorized_keys, with no password changes for anyone else. We cover deployment over SSH and Git in modern WordPress deployment with SSH and Git.

Hosting, domain registrar, CDN accounts and premium plugin licences should belong to the client or the agency. The developer gets access to them as a user, not as the owner.

#How to revoke access when the engagement ends

A checklist for the day the contract ends, ideally written into the contract as an obligation on both sides:

1. Search Console: remove the user and all of their verification tokens (file, meta tag, DNS record).
2. WordPress: delete the developer’s accounts on production and staging, and attribute their content to another user.
3. Server: remove their SSH keys from authorized_keys, their SFTP accounts and any database accounts.
4. Repository: remove access to the organisation, deploy keys and CI secrets.
5. Hosting, CDN, DNS manager, billing panel: remove the user, and where an account was shared, rotate the password and API keys.
6. Third-party tools: Google Analytics, Tag Manager, monitoring, the password manager.
7. Data: written confirmation that the developer has deleted or returned copies of databases and files containing personal data (a requirement under GDPR article 28(3)(g), covered below).

If you cannot work through this list in an hour, access was granted too broadly or on shared accounts.

#Core Web Vitals: what the developer fixes and what the host fixes

The thresholds come from web.dev (vitals). They are measured at the 75th percentile of page loads, separately for mobile and desktop.

INP became a stable Core Web Vital in 2024 and replaced FID. Client reports written before that change, still talking about FID, describe a metric Google no longer uses in this set.

The split of responsibility follows what each metric is made of. LCP includes connection time, redirects and server response, and only then the loading and rendering of the element. Part of that time belongs to the host, part to the theme.

A developer who answers every poor score with “it’s the hosting” is not showing a measurement. A good partner splits a high TTFB into PHP, database and network time, and only then names the culprit. If the client needs a separate diagnosis before deciding on changes, that is what the Core Web Vitals audit is for, and the fixes themselves are described on the page about speeding up WordPress. For a technical walkthrough of the metrics, see the WordPress performance guide: Core Web Vitals, caching and images.

#What to put in a WordPress developer retainer contract

A standing contract with a developer sells two things: reserved time and a predictable response. The contract should describe both clearly enough that, three months in, nobody has to guess what was agreed.

#Scope and hours

The monthly cap on hours, how they are billed (for example in 15-minute increments), what the package covers and what it does not. Sample wording:

The Contractor reserves 24 hours of work for the Client in each calendar month. Hours not used in a given month do not carry over to later months.

No rollover looks like it only benefits the developer, but it makes sense on both sides. The developer turns other clients away to hold that time for the agency. If hours piled up indefinitely, after six months the agency could demand several dozen hours in a single week, which nobody can deliver. If hours are regularly left over, the package is too big.

#Response time and fix time

These are two different commitments. Response time is the acknowledgement, the initial diagnosis and the plan. Fix time depends on the cause, and nobody knows the cause before the diagnosis. Sample wording:

Response time means acknowledgement of the ticket together with an initial diagnosis and a plan for next steps. Response time is counted on working days, Monday to Friday, during business hours in Central European Time. Response time is not a deadline for resolving the fault.

For a UK or Irish agency, write the time zone into the clause rather than assuming it. CET is one hour ahead of UK and Irish time, so a developer’s 17:00 close is your 16:00. That hour matters when a client reports a broken checkout at 16:30 on a Friday.

Also define each priority (for example P1: production or orders are down; P2: a release is blocked; P3: development and optimisation) and say who assigns the priority. Without definitions every client ticket becomes P1.

#Out-of-hours work

If the SLA runs on working days, say plainly that evenings, weekends and incidents outside those hours need a separate written agreement. An agency that promises its client round-the-clock cover while its developer works office hours is selling something it does not have.

#Larger work outside the package

A migration, a new content type or a template rebuild rarely fits in the monthly cap. The contract should state that any task above a set number of hours gets its own written scope, estimate and sign-off before work starts.

#Initial term and notice

At the start of the engagement part of the time goes into learning the client sites, the access setup and the agency’s process. A longer first term makes sense for that reason, followed by a monthly contract with a stated notice period.

#White-label, confidentiality and non-solicitation

A non-disclosure agreement signed before any client names or credentials change hands. A rule that the developer talks to the end client only when the agency wants them to. A ban on the developer pitching the end client directly during the engagement and for a set period after it.

#Definition of a ready ticket

Put the five elements described in what a ready ticket looks like into the contract as the definition. Add one sentence on what happens to a ticket that misses them: it goes back to the agency with questions, and the contract says whether the time spent on those questions counts against the package.

#The first two months in practice

The initial term is when the habits are set, so plan it. In week one the developer should receive access per person, as described above, plus one pilot ticket that touches staging, the repository and a release to production. That one ticket tests the whole chain: whether staging is a faithful copy, whether the deploy path works, and whether your ticket format gives the developer enough to start. In the following weeks, agree a fixed day for the hours summary and the measurement table described below. By the end of the second month you will know whether the package size matches your backlog, which is the point at which a monthly rolling contract should begin.

If you are choosing a partner for a whole site rather than an hourly retainer, our piece on how to choose a WordPress agency will help. Ongoing care of a single site with no development work is covered by WordPress website maintenance.

#Who owns the copyright in code written for an agency’s client

Both UK and Irish law start from the same position: the author is the first owner, and the employer exception is narrow.

In the United Kingdom, section 11(1) of the Copyright, Designs and Patents Act 1988 makes the author the first owner. Section 11(2) makes the employer the first owner only where the work is made by an employee in the course of their employment, subject to any agreement to the contrary (legislation.gov.uk, s.11). In Ireland, section 23(1)(a) of the Copyright and Related Rights Act 2000 follows the same pattern: the author is the first owner unless the work is made by an employee in the course of employment, in which case the employer is the first owner, again subject to any agreement to the contrary (irishstatutebook.ie, s.23).

A freelance developer, a sole trader or a developer’s limited company working on a services contract is not your employee. Paying an invoice does not change that. Without a written assignment the code the developer wrote for your client stays theirs, and your client is using it on terms nobody wrote down.

Ownership therefore moves only by contract, and the form of that contract is set by statute:

Signed is the operative word in both statutes. The assignor, here the developer or their company, has to sign. A signature from the agency alone on its own terms of business does not do it.

Two drafting points are worth your solicitor’s attention. First, state that the assignment covers the code the developer writes for the agency’s clients and that the agency may pass the copyright on to those clients. An agency that holds the rights but whose contract is silent on handing them to the end client invites an argument at exactly the wrong moment, usually when the client moves to another supplier. Second, tie the assignment to a recurring event such as monthly acceptance. Each month then has its own signed record that matches the hours summary and the invoice.

Sample wording, for your solicitor to review and adapt to English, Northern Irish, Scottish or Irish law as applicable:

On signature of the acceptance record for a given month, the Contractor assigns to the Client all copyright in the code created under this Agreement in that month, including the right to reproduce, adapt, modify and make it available to the public online, and the Client may assign or license these rights to its own clients.

The contract does not cover WordPress itself. WordPress is released under GPLv2 or later, and WordPress.org considers plugins and themes to be derivative works that inherit the GPL (wordpress.org). The assignment concerns the code the developer wrote for the agency. That code should go into the agency’s or the client’s repository from day one. Rights on paper are worth little if the only copy of the code sits on the developer’s laptop.

#Is an external developer a processor under GDPR

Almost always, if they have access to databases holding personal data: WooCommerce orders, contact forms, user accounts, newsletter lists. The usual chain looks like this: the agency’s client is the controller, the agency is the processor, and the developer the agency brings in to work on that data is a sub-processor.

For an Irish agency, and for any agency whose client is established in the EU, the frame is the EU GDPR, which applies directly. Article 28(2) (EUR-Lex) reads: “The processor shall not engage another processor without prior specific or general written authorisation of the controller.” For a UK agency serving UK clients the same article applies as part of UK GDPR, with the same wording in paragraph 2 (legislation.gov.uk, UK GDPR art. 28). The UK text of paragraph 4 requires the sub-processor’s obligations to be imposed “by way of a contract or other legal act under domestic law”, where the EU text refers to Union or Member State law; that substitution has been in force since 31 December 2020.

With general authorisation the agency tells the client about any intended addition or replacement of a sub-processor, and the client can object. Article 28(4) requires the same data protection obligations the agency owes the client to be imposed on the sub-processor by contract. If the developer fails to meet them, the agency remains fully liable to the client.

In practice that means three documents:

1. In the agency’s contract with the client: authorisation (specific or general) to use sub-processors, naming the developer or setting out how the client will be notified.
2. A data processing agreement between the agency and the developer that carries over the obligations in article 28(3): processing only on documented instructions, confidentiality for everyone with access, the security measures under article 32, help with data subject requests, deletion or return of data when the services end, and making information available for audits.
3. A working rule for data: staging with anonymised or reduced data, a copy of the production database only when the task requires it, and deletion of that copy once the ticket closes.

A UK agency with clients on both sides of the Irish Sea will usually end up with the same processing agreement referring to UK GDPR for UK clients and to the EU GDPR for clients in Ireland or elsewhere in the EU. Your solicitor should confirm how to structure that for your client base.

Sample clause on data in staging:

The Contractor shall not move a copy of the production database outside the infrastructure designated by the Client. Where a task requires work on a copy of the data, the Contractor shall delete it within 7 days of the ticket closing and confirm this in the ticket.

#How to measure a retained developer’s results

An hours report tells you how much time was used. It does not tell you whether the client’s site works any better. Measurement has to be planned for each task before the developer starts.

For performance tasks the source is field data. The CrUX API provides a 28-day rolling average of aggregated metrics and updates daily at around 04:00 UTC (developer.chrome.com). Only publicly discoverable pages with enough visits make it into the dataset, so a small page may have no URL-level data, only origin-level data for the whole domain. The Core Web Vitals report in Search Console uses the same CrUX data, groups similar URLs and gives a group the status of its weakest metric. Once a fix is released, the start tracking button opens a 28-day window: if the issue does not appear on any URL in that time, Google considers it fixed (support.google.com).

That sets the rhythm: measure before, record the release date, measure again after at least 28 days. A report a week after release shows a mix of old and new page loads.

For SEO tasks (redirects, indexing, structured data) the measurement comes from Search Console reports: the indexing status of the listed URLs, the enhancement report for the structured data type in question, and search performance for a group of pages before and after the change.

A simple monthly report format the agency can pass on to the client under its own brand:

The number fields are filled from tool data, not estimates. The “measurement status” column stops you reporting a success that is not yet visible.

#How to spot a bad white-label partner

Warning signs when choosing a developer or a firm that will work under your brand:

• Unlimited tickets for a flat fee. Somebody pays for the missing limit, and it is usually a queue where your ticket waits with no deadline.
• No written response time. “We reply quickly” is not a commitment. Ask for the response time on a critical priority and the hours in which it applies.
• A promised fix time for every incident. Nobody knows the cause before the diagnosis. A guaranteed two-hour fix with no conditions means nobody thought the contract through.
• Hours that roll over forever. It sounds generous, but it builds a time debt the partner cannot repay all at once.
• No staging. A developer who ships changes straight to the client’s production site moves the risk onto your agency.
• Shared accounts and one password for the team. You cannot tell who changed what, or remove one person’s access.
• Search Console verified with the developer’s own account. When you part ways the tokens stay behind, and with them a way back in.
• Code only on the server, with no agency or client repository. A signed assignment will not help if you do not have the code.
• No processing agreement. A partner who never asks about personal data is not thinking about the liability your agency carries for them towards the client.
• A partner who wants contact with the end client from day one. White-label means the agency decides whether and when that happens.

#How Agency Development Desk works

Agency Development Desk is our retained service for SEO, branding and design agencies that have no WordPress and WooCommerce developer of their own. It runs on the same rules this guide describes as safe:

• three packages with a monthly cap on hours: Desk Flex (10 h), Desk Core (24 h) and Desk Embedded (48 h), each with a written first response time that depends on priority;
• the SLA runs on CET working days, and evening, weekend and emergency work needs a separate written agreement;
• a response means acknowledgement, initial diagnosis and a plan, not a guaranteed fix within the same time;
• unused hours do not carry over to the next month, because that capacity was reserved for the agency;
• the first term is two months, after which the package runs monthly with one month’s notice;
• larger sprints get their own written scope, estimate and sign-off;
• an NDA before any access is shared, white-label delivery within the agency’s process, and non-solicitation written into the contract;
• code goes into a repository the agency or the client controls, and accounts and licences do not depend on us.

We take work as written tickets with the expected result, links, environment and acceptance criteria, with no mandatory meetings. Package prices are on the service page. To check the fit, an email is enough: the kind of clients you serve, your stack, a sample backlog from your latest audit and the number of hours you expect each month.