Outsourcing WordPress para agências SEO: como contratar desenvolvimento num retainer

Uma agência SEO vende audits, estratégia de conteúdos e link building. Depois do audit fica uma lista de tarefas, e parte delas exige alterações no tema, nas extensões ou na configuração do servidor. Sem programador WordPress na equipa a lista fica parada, e o cliente pergunta em julho porque é que o relatório de março ainda não teve efeito. Este guia explica como passar esse trabalho a um programador externo num retainer mensal: o que entregar, como dar acesso sem partilhar contas, o que pôr no contrato à luz do direito português e do RGPD, e como verificar se o trabalho produz resultado.

Os excertos sobre direitos de autor e proteção de dados resumem o direito à data de 24 de outubro de 2026, para agências em Portugal. Não são aconselhamento jurídico individual. As cláusulas-modelo são rascunhos para o seu advogado rever, não texto contratual pronto a assinar.

#Em resumo

• A agência fica com o diagnóstico, as prioridades e a relação com o cliente. O programador responde pela implementação e por a alteração não partir a produção.
• Dá acesso a uma pessoa, não a uma empresa: utilizador próprio na Search Console, conta própria no WordPress, chave SSH própria. Cada um revoga-se num único passo.
• No contrato ficam o teto mensal de horas, o tempo até à primeira resposta (separado do tempo de reparação), o modo de orçamentar trabalhos maiores, white-label e confidencialidade.
• O código de um programador externo pertence-lhe enquanto os direitos não forem transmitidos ou onerados nos termos do CDADC; um e-mail a dizer “cedo os direitos” não chega.
• Um programador com acesso a sites com dados pessoais é subcontratante ulterior; precisa da autorização do cliente e de um contrato de subcontratação do tratamento.
• Mede por tarefa: estado antes, data de publicação, estado após 28 dias de dados CrUX ou da Search Console.

#Glossário para donos de agência

#Que tarefas do audit SEO precisam de um programador WordPress

Um audit técnico costuma acabar numa lista de achados, não numa lista de nomes. O primeiro passo é separar quem faz o quê. A divisão abaixo segue o sítio da alteração: conteúdo e definições do painel, ou código e servidor.

Quando envia um ticket ao programador, a coluna “agência SEO” diz o que ele espera de si: lista de URLs, dados da Search Console, mapa de redirecionamentos. Um ticket sem esses dados começa com perguntas, e as perguntas comem horas do pacote. Sobre a origem das semanas de espera por alterações simples, escrevemos em porque é que as alterações WordPress demoram semanas.

#Como é um ticket pronto a começar

Um ticket em que o programador pode começar sem resposta contém cinco coisas: resultado esperado, URLs, ambiente (staging ou produção), dados para reproduzir o problema e critério de aceitação. Numa tarefa de redirecionamentos após migração isso significa a folha de cálculo de URLs antigas e novas, nota sobre strings de consulta, a data em que as URLs antigas saíram do sitemap e o teste que fecha o ticket (“cada URL da coluna A devolve um único 301 para a coluna B”). Numa tarefa de desempenho: o template, três URLs de exemplo, o LCP p75 mobile da Search Console e o elemento que o Lighthouse aponta como LCP. Escrever isto leva dez minutos. Um pedaço em falta custa uma ronda de e-mail, e com um programador em horário CET uma ronda pode custar um dia útil.

#Como dar acesso à Search Console sem partilhar a conta

A Search Console tem cinco níveis de acesso. As descrições vêm da documentação da Google sobre utilizadores e permissões (support.google.com).

O programador quase nunca precisa de ser proprietário. O acesso total chega: vê todos os relatórios, enquanto adicionar utilizadores e alterar definições fica nos proprietários.

Os tokens são o que se esquece no fim do contrato. Segundo a mesma página da Google, um proprietário removido perde o acesso, mas os respetivos tokens de verificação não são removidos nem invalidados. Se o token (ficheiro HTML, meta tag, registo DNS) continua no site ou no domínio, a pessoa pode voltar a verificar a propriedade. Por isso um programador externo não deve verificar a propriedade com a própria conta. Se alguma vez o fez, no fim remove o utilizador e o token. A Google avisa no painel: se ao remover aparecer que o utilizador pode recuperar o acesso, os tokens ainda estão lá.

Se se removerem todos os proprietários verificados, os restantes utilizadores e proprietários delegados perdem o acesso após um período transitório. O proprietário verificado deve ser o cliente; a agência e o programador trabalham com acesso que o cliente controla.

#Que função WordPress dar a um programador externo

O WordPress tem seis funções predefinidas. A documentação em wordpress.org descreve-as assim: Super Administrador gere uma rede multisite, Administrador tem acesso a todas as funções administrativas de um site individual, Editor publica e gere artigos incluindo os de outros, Autor publica os próprios artigos, Colaborador escreve sem publicar e Assinante gere só o próprio perfil.

Numa instalação individual só o Administrador tem, entre outras, estas capacidades: update_core, update_plugins, install_plugins, edit_plugins, edit_themes, edit_files, create_users, delete_users e unfiltered_html. Em multisite só o Super Admin as tem. Um programador que tenha de atualizar ou instalar extensões precisa portanto da função Administrador no staging e, em regra, também na produção. A função Editor não chega para trabalho técnico.

Como a conta do programador é de administrador, a higiene à volta dela importa:

• Conta separada por pessoa. Um login partilhado “agencia-dev” significa que não sabe quem alterou o quê e não consegue retirar o acesso a uma pessoa sem mudar a palavra-passe a todos.
• Edição de ficheiros desligada no painel. A documentação de hardening do WordPress (developer.wordpress.org) indica que define( 'DISALLOW_FILE_EDIT', true ); em wp-config.php equivale a retirar a todos os utilizadores edit_themes, edit_plugins e edit_files. O programador deve publicar código a partir de um repositório, não pelo editor do painel.
• Staging com ambiente declarado. A função wp_get_environment_type() devolve local, development, staging ou production e, se nada estiver definido, assume production (developer.wordpress.org). Com staging na cópia, o código e as extensões podem comportar-se de outra forma, por exemplo sem enviar e-mails aos clientes da loja.
• SFTP ou SSH em vez de FTP. A mesma documentação recomenda SFTP porque a palavra-passe e os dados vão encriptados. Na prática uma chave SSH por pessoa funciona melhor: revogar o acesso é apagar uma linha de authorized_keys, sem mudar palavras-passe a ninguém. Sobre publicação por SSH e Git escrevemos em deixe de usar FTP: deployment moderno de WordPress com SSH e Git.

Contas de alojamento, registador de domínio, CDN e licenças de extensões premium devem pertencer ao cliente ou à agência. O programador recebe acesso como utilizador, não como proprietário.

#Como revogar acessos no fim da colaboração

Lista para o dia em que o contrato termina, de preferência escrita no contrato como obrigação de ambas as partes:

1. Search Console: remover o utilizador e todos os seus tokens de verificação (ficheiro, meta tag, registo DNS).
2. WordPress: apagar as contas do programador na produção e no staging e atribuir os conteúdos a outro utilizador.
3. Servidor: remover as chaves SSH de authorized_keys, contas SFTP e eventuais contas de base de dados.
4. Repositório: retirar o acesso à organização, chaves de deployment e segredos de CI.
5. Alojamento, CDN, gestor de DNS, painel de faturação: remover o utilizador e, onde a conta era partilhada, rodar palavra-passe e chaves API.
6. Ferramentas externas: Google Analytics, Tag Manager, monitorização, gestor de palavras-passe.
7. Dados: confirmação por escrito de que o programador apagou ou devolveu cópias de bases e ficheiros com dados pessoais (exigência do art. 28.º n.º 3, alínea g, do RGPD, descrita abaixo).

Se esta lista não se fizer numa hora, os acessos foram dados de forma demasiado ampla ou em contas partilhadas.

#Core Web Vitals: o que o programador corrige e o que o alojamento corrige

Os limiares vêm do web.dev (vitals). Medem-se no percentil 75 das visualizações, em separado para telemóvel e computador.

O INP passou a métrica estável dos Core Web Vitals em 2024 e substituiu o FID. Relatórios de clientes anteriores a essa mudança que ainda falam de FID descrevem uma métrica que a Google já não usa neste conjunto.

A divisão de responsabilidades segue a composição de cada métrica. O LCP inclui tempo de ligação, redirecionamentos e resposta do servidor e só depois o carregamento e a renderização do elemento. Parte desse tempo é do alojamento, parte do tema.

Um programador que responde a cada resultado fraco com “é culpa do alojamento” não mostra uma medição. Um bom parceiro parte um TTFB alto em tempo de PHP, base e rede e só depois aponta o culpado. Se o cliente precisa de um diagnóstico próprio antes de decidir alterações, serve para isso a auditoria Core Web Vitals; as correções em si estão descritas na página sobre como acelerar um site WordPress. A visão técnica das métricas está no guia definitivo de performance WordPress: Core Web Vitals, cache e imagens.

#O que pôr no contrato de retainer com o programador WordPress

Um contrato permanente com um programador vende duas coisas: tempo reservado e resposta previsível. O contrato deve descrever ambas de forma a que, ao fim de três meses, ninguém tenha de adivinhar o que ficou acordado.

#Âmbito e horas

Teto mensal de horas, modo de faturação (por exemplo em quartos de hora), o que entra no pacote e o que não entra. Formulação-exemplo:

O Prestador reserva para o Cliente 24 horas de trabalho em cada mês civil. As horas não utilizadas num dado mês não transitam para os meses seguintes.

A ausência de trânsito parece favorecer só o programador, mas tem fundamento dos dois lados. O programador recusa outros clientes para guardar esse tempo para a agência. Se as horas se acumulassem sem fim, ao fim de meio ano a agência poderia exigir dezenas de horas numa só semana, o que ninguém consegue entregar. Se as horas ficam regularmente por usar, o pacote é grande demais.

#Tempo de resposta e tempo de reparação

São dois compromissos diferentes. Tempo de resposta é confirmação, diagnóstico inicial e plano. Tempo de reparação depende da causa, e essa ninguém conhece antes do diagnóstico. Formulação-exemplo:

Tempo de resposta significa a confirmação de receção do ticket juntamente com um diagnóstico inicial e um plano das ações seguintes. O tempo de resposta conta-se em dias úteis, de segunda a sexta, em horário laboral segundo a hora da Europa Central (CET). O tempo de resposta não é um prazo de resolução da anomalia.

Para uma agência em Portugal continental, a CET coincide com a hora local; na Madeira e nos Açores a diferença horária importa. Escreva a fuso no contrato em vez de o assumir.

Defina também cada prioridade (por exemplo P1: produção ou encomendas em baixo; P2: publicação bloqueada; P3: desenvolvimento e otimização) e quem atribui a prioridade. Sem definições, cada ticket do cliente vira P1.

#Trabalho fora de horas

Se o SLA corre em dias úteis, diga claramente que noites, fins de semana e incidentes fora dessas horas exigem acordo escrito à parte. Uma agência que promete ao cliente cobertura permanente e tem o programador em horário de escritório está a vender o que não tem.

#Trabalhos maiores fora do pacote

Uma migração, um novo tipo de conteúdo ou a reconstrução de templates raramente cabem no teto mensal. O contrato deve dizer que uma tarefa acima de um número definido de horas recebe âmbito escrito próprio, estimativa e aprovação antes de começar.

#Período inicial e denúncia

No início da colaboração parte do tempo vai para conhecer os sites dos clientes, os acessos e o processo da agência. Por isso faz sentido um primeiro período mais longo e, a seguir, um contrato mensal com prazo de denúncia definido.

#White-label, confidencialidade e não angariação

Acordo de confidencialidade assinado antes de se passarem nomes de clientes e credenciais. Regra de que o programador fala com o cliente final só quando a agência quiser. Proibição de apresentar oferta própria ao cliente final durante a colaboração e por um período definido após o fim.

#Definição de ticket pronto

Um ticket contém o resultado esperado, as URLs, o ambiente, os dados para reproduzir o problema e o critério de aceitação. Um ticket sem isto volta à agência com perguntas; se o tempo dessas perguntas conta no pacote também deve ficar escrito.

#Os primeiros dois meses na prática

O período inicial é quando se fixam os hábitos. Na primeira semana o programador deve receber acesso por pessoa, como acima, mais um ticket-piloto que toque no staging, no repositório e numa publicação em produção. Esse ticket único testa a cadeia toda: se o staging é cópia fiel, se o caminho de deploy funciona e se o formato do ticket chega para começar. Nas semanas seguintes, combine um dia fixo para o resumo de horas e a tabela de medição abaixo. No fim do segundo mês sabe se o tamanho do pacote corresponde ao backlog; é aí que o contrato mensal rolante deve começar.

Se escolhe um parceiro para o site inteiro e não para um retainer de horas, o texto como escolher uma agência WordPress ajuda. A manutenção contínua de um site individual sem desenvolvimento está descrita em manutenção de sites WordPress.

#Quem tem os direitos de autor sobre o código escrito para o cliente da agência

O Código do Direito de Autor e dos Direitos Conexos (CDADC) português (PGDL) parte da titularidade do criador intelectual e exige formalidades fortes para transmitir direitos.

O art. 14.º dispõe que, nas obras feitas por encomenda ou por conta de outrem, a titularidade segue o acordo; na ausência de acordo, presume-se titular o criador intelectual. Um programador externo que fatura à agência não é trabalhador por conta de outrem da agência no sentido de cessão automática: sem acordo escrito válido, a presunção do art. 14.º fica do lado do criador.

As formas de transmissão são rigorosas:

Na prática, o caminho comum é a licença ou a transmissão parcial com documento escrito e reconhecimento notarial das assinaturas, e não a transmissão total por escritura, que exige também o preço da transmissão. A escolha entre licença, transmissão parcial e transmissão total depende do que a agência precisa de poder fazer e passar ao cliente final. Peça a um advogado português que escolha a figura e redija a cláusula; o texto abaixo é só um ponto de partida para essa conversa, não um modelo pronto.

Pontos que o advogado deve cobrir: o direito de alterar o código, o direito de o disponibilizar em rede, e o direito de transmitir ou sublicenciar esses direitos aos clientes da agência. Sem este último, a agência pode ter direitos e não os poder entregar ao cliente quando ele muda de fornecedor. Em colaboração contínua, faz sentido amarrar cada transmissão ou licença a um evento recorrente, por exemplo a aceitação mensal, para que cada mês tenha o seu registo formal alinhado com o resumo de horas e a fatura.

Formulação-exemplo, para revisão pelo advogado da agência:

Com a assinatura da ata de aceitação do mês respetivo, o Prestador transmite ao Cliente, na medida e sob a forma que o CDADC exigir (incluindo, se aplicável, reconhecimento notarial das assinaturas), os direitos patrimoniais sobre o código criado nesse mês ao abrigo deste contrato, incluindo a reprodução, a adaptação, a modificação e a disponibilização pública em rede, com direito de transmissão ulterior aos clientes do Cliente.

O contrato não cobre o próprio WordPress. O WordPress é publicado sob GPLv2 ou posterior, e o WordPress.org considera extensões e temas obras derivadas que herdam a GPL (wordpress.org). A transmissão ou licença respeita ao código que o programador escreveu para a agência. Esse código deve entrar no repositório da agência ou do cliente desde o primeiro dia. Direitos no papel pouco valem se a única cópia estiver no portátil do programador.

#O programador externo é subcontratante no RGPD

Quase sempre, se tiver acesso a bases com dados pessoais: encomendas WooCommerce, formulários de contacto, contas de utilizador, listas de newsletter. A cadeia costuma ser: o cliente da agência é o responsável pelo tratamento, a agência é o subcontratante, e o programador a quem a agência encarrega trabalho sobre esses dados é subcontratante ulterior.

O art. 28.º n.º 2 do RGPD (EUR-Lex) diz: “O subcontratante não recruta outro subcontratante sem autorização prévia por escrito, específica ou geral, do responsável pelo tratamento.” Com autorização geral, a agência informa o cliente de qualquer adição ou substituição prevista de subcontratantes ulteriores, e o cliente pode opor-se. O art. 28.º n.º 4 exige que ao subcontratante ulterior se imponham por contrato as mesmas obrigações de proteção de dados que a agência tem perante o cliente. Se o programador as não cumprir, a agência continua plenamente responsável perante o cliente.

Na prática isso significa três documentos:

1. No contrato da agência com o cliente: autorização (específica ou geral) para recorrer a subcontratantes ulteriores, com o nome do programador ou com o mecanismo de informação.
2. Contrato de subcontratação do tratamento entre a agência e o programador que reproduz as obrigações do art. 28.º n.º 3: tratamento só segundo instruções documentadas, confidencialidade das pessoas com acesso, medidas de segurança do art. 32.º, auxílio nos pedidos dos titulares, apagamento ou devolução dos dados no fim do serviço, e disponibilização de informação para auditorias.
3. Regra de trabalho com dados: staging com dados anonimizados ou reduzidos, cópia da base de produção só quando a tarefa o exigir, e apagamento dessa cópia após o fecho do ticket.

Cláusula-exemplo sobre dados em staging:

O Prestador não desloca cópia da base de dados de produção para fora da infraestrutura indicada pelo Cliente. Se a tarefa exigir trabalho sobre uma cópia dos dados, o Prestador apaga-a no prazo de 7 dias após o fecho do ticket e confirma-o no ticket.

#Como medir os resultados do programador em retainer

Um relatório de horas diz quanto tempo se gastou. Não diz se o site do cliente funciona melhor. A medição tem de ser planeada por tarefa antes de o programador começar.

Para tarefas de desempenho a fonte são os dados de campo. A API CrUX dá uma média móvel de 28 dias de métricas agregadas e atualiza-se diariamente por volta das 04:00 UTC (developer.chrome.com). Só páginas publicamente detetáveis e com visitas suficientes entram no conjunto, pelo que uma página pequena pode não ter dados ao nível do URL, só ao nível da origem do domínio. O relatório Core Web Vitals na Search Console usa os mesmos dados CrUX, agrupa URLs semelhantes e atribui ao grupo o estado da métrica mais fraca. Depois de publicar a correção, o botão de início de acompanhamento abre uma janela de 28 dias: se o problema não aparecer em nenhum URL nesse período, a Google considera-o resolvido (support.google.com).

Daí o ritmo: medir antes, registar a data de publicação, medir de novo após pelo menos 28 dias. Um relatório uma semana depois da publicação mistura visualizações antigas e novas.

Para tarefas SEO (redirecionamentos, indexação, dados estruturados) a medição vem dos relatórios da Search Console: estado de indexação das URLs indicadas, relatório de melhorias do tipo de dados estruturados em causa, e desempenho de pesquisa de um grupo de páginas antes e depois da alteração.

Formato simples de relatório mensal que a agência pode enviar ao cliente sob a própria marca:

Os campos numéricos preenchem-se com dados das ferramentas, não com estimativas. A coluna “estado da medição” evita reportar um sucesso que ainda não se vê.

#Como reconhecer um mau parceiro white-label

Sinais de alerta ao escolher um programador ou uma empresa que vá trabalhar sob a sua marca:

• Tickets ilimitados a preço fixo. Alguém paga a falta de teto, normalmente uma fila em que o seu ticket espera sem prazo.
• Sem tempo de resposta por escrito. “Respondemos depressa” não é compromisso. Pergunte o tempo de resposta para prioridade crítica e as horas em que vale.
• Promessa de tempo de reparação para cada incidente. Ninguém conhece a causa antes do diagnóstico. Garantia de reparação em 2 horas sem reservas significa que o contrato não foi pensado.
• Horas que transitam sem fim. Soa generoso, mas cria uma dívida de tempo que o parceiro não consegue pagar de uma vez.
• Sem staging. Quem publica alterações direto na produção do cliente passa o risco para a sua agência.
• Contas partilhadas e uma só palavra-passe para a equipa. Não consegue saber quem alterou o quê nem retirar o acesso a uma pessoa.
• Search Console verificada com a conta do programador. No fim ficam tokens, e com eles um caminho de regresso.
• Código só no servidor, sem repositório da agência ou do cliente. Direitos no papel não ajudam se não tiver o código.
• Sem contrato de subcontratação do tratamento. Um parceiro que nunca pergunta por dados pessoais não pensa na responsabilidade que a sua agência assume por ele perante o cliente.
• Parceiro que quer contacto com o cliente final desde o primeiro dia. White-label significa que a agência decide se e quando isso acontece.

#Como funciona o Agency Development Desk

O balcão de desenvolvimento para agências é o nosso serviço permanente para agências SEO, de branding e de design sem programador WordPress e WooCommerce próprio. Corre segundo as mesmas regras que este guia descreve como seguras:

• três pacotes com teto mensal de horas: Desk Flex (10 h), Desk Core (24 h) e Desk Embedded (48 h), cada um com tempo escrito até à primeira resposta conforme a prioridade;
• o SLA corre em dias úteis CET, e trabalho noturno, de fim de semana e de emergência exige acordo escrito à parte;
• resposta significa confirmação, diagnóstico inicial e plano, não garantia de reparação no mesmo prazo;
• as horas não utilizadas não passam para o mês seguinte, porque essa capacidade estava reservada para a agência;
• o primeiro período dura dois meses; depois o pacote corre mensalmente com um mês de denúncia;
• sprints maiores recebem âmbito escrito próprio, estimativa e aprovação;
• NDA antes de qualquer acesso, entrega white-label no processo da agência e não angariação no contrato;
• o código vai para um repositório controlado pela agência ou pelo cliente, e contas e licenças não dependem de nós.

Aceitamos trabalho em tickets escritos com resultado esperado, ligações, ambiente e critério de aceitação, sem reuniões obrigatórias. Os preços dos pacotes estão na página do serviço. Para avaliar o encaixe basta um e-mail: tipo de clientes que serve, stack, exemplo de backlog do último audit e número de horas esperado por mês.