Working With a Marketing Agency: A Technical Guide for Developers and Designers

Community Article
Community articles are authored by SitePoint Premium contributors. Content is screened before publication, and SitePoint reserves the right to moderate or remove articles that violate our guidelines. Views expressed are those of the authors and do not necessarily reflect those of SitePoint.

Working With a Marketing Agency: A Technical Guide for Developers and Designers

DJDiv JohnPublished inBest Practices·
October 21, 2026
·Updated:October 21, 2026

The AI briefing for Developers

Stay up to date with AI tools, model releases, and developer workflows that matter.

Weekly. Free. One click to leave.

SitePoint Premium
Stay Relevant and Grow Your Career in Tech

• Premium Results
• Publish articles on SitePoint
• Daily curated jobs
• Learning Paths
• Discounts to dev tools

7 Day Free Trial. Cancel Anytime.

Sooner or later, most teams that build websites end up working alongside a digital marketing agency. The agency asks for CMS access, wants tracking scripts added, suggests URL changes, and sets targets for page speed. If nobody on the product side understands what is being asked and why, the result is broken analytics, accidental noindex tags, and migrations that quietly erase years of search visibility.

This guide is for developers, designers, and technical founders. It covers the engineering side of that collaboration: environments and access, analytics implementation, redirects, structured data, performance budgets, and crawler access, with code you can adapt and a checklist you can hand to whoever you are working with.

Why Marketing Results Depend on Engineering Decisions

Marketing briefs rarely say it, but most outcomes are decided in the codebase and the design system:

• Rendering: if key content only appears after client-side JavaScript runs, crawlers and AI systems may index it late or not at all.
• Performance: Core Web Vitals (LCP, INP, CLS) are shaped by images, fonts, third-party scripts, and layout decisions that designers and developers own.
• Measurement: conversion tracking only works if events fire reliably, which means someone has to implement and test them.
• Information architecture: URL structure, internal linking, and navigation shape both usability and search performance.

That is why healthy collaborations look like a shared engineering effort with a reviewable change process, not a monthly PDF report.

Where These Collaborations Usually Break

Almost every painful marketing-and-engineering story falls into one of the patterns below. Each has a cause you can see in the code and a fix that takes minutes, if you catch it before launch.

A Technical Checklist for Working With an Agency

1. Agree on environments and access

Give the agency a staging environment and least-privilege access rather than production admin rights. Keep staging out of search results so test pages are never indexed. At the web-server level that can be a single header:

# nginx: keep a staging site out of search resultsadd_header X-Robots-Tag"noindex, nofollow" always;

The risk is the other direction: that header reaching production. Add a post-deploy check to your pipeline so a launch fails loudly instead of silently:

# fail the deploy if production sends a noindex header or meta tagURL="https://example.com/"if curl -sI "$URL"| grep -qi "x-robots-tag:.*noindex"; thenecho "noindex header found on production"; exit 1fiif curl -s "$URL"| grep -qi '<meta[^>]*name="robots"[^>]*noindex'; thenecho "noindex meta tag found on production"; exit 1fi

2. Standardize analytics and campaign tagging

Reports are only as good as the data behind them. Agree on a naming convention for UTM parameters before the first campaign, and document it:

https://example.com/pricing?utm_source=newsletter&utm_medium=email&utm_campaign=2026-q4-launch

For conversions, prefer explicit events pushed to a data layer over fragile click-based triggers. Developers implement them once, and every tool downstream can reuse them:

window.dataLayer=window.dataLayer||[];window.dataLayer.push({event:'generate_lead',form_id:'contact-main',page_type:'pricing'});

Test each event in your tag manager’s preview mode on staging, and treat event names and parameters as part of your API: changing them is a breaking change that should be announced.

3. Protect search equity during redesigns and migrations

Changing URLs without redirects discards accumulated search visibility. Before launch, export every indexable URL, map each to its new location, and implement permanent redirects:

# nginx: permanent redirect from an old URL to its newhomelocation=/old-services/seo {return301/services/search-engine-optimization;}

Do not rely on spot checks. This script reads a two-column CSV of old and new paths and verifies that each old URL returns a single 301 to a destination that returns 200:

import csvimport sysimport requestsdef check(base, mapping_csv):failures =0withopen(mapping_csv, newline="")asf:for old,newin csv.reader(f):hop = requests.get(base + old, allow_redirects=False, timeout=10)dest = requests.get(base +new, allow_redirects=False, timeout=10)location= hop.headers.get("Location","")ok =(hop.status_code==301and location.rstrip("/").endswith(new.rstrip("/"))and dest.status_code==200)if not ok:failures +=1print(f"FAIL {old}: {hop.status_code} -> {location} (target {dest.status_code})")return failuresif __name__ =="__main__":sys.exit(1ifcheck(sys.argv[1], sys.argv[2])else0)

Run it against staging before launch and against production right after. Redirect chains (A to B to C) and redirects that land on a 404 are the two failures it catches most often.

4. Make content machine-readable

Structured data helps search engines and AI systems understand who you are. Generate it from the same data that renders the page, so it never drifts from the visible content, and escape it properly when you embed it:

functionorganizationJsonLd(org){const data ={"@context":"https://schema.org","@type":"Organization",name: org.name,url: org.url,logo: org.logoUrl,};return`<script type="application/ld+json">${JSON.stringify(data).replace(/</g,"\u003c")}</script>`;}

Validate the output with Google’s Rich Results Test or the Schema Markup Validator as part of review, not after launch. If you would rather not hand-write the JSON-LD for every page type,free Schema Markup Generator can produce a starting point, which you should still validate with the tools above.

5. Set performance budgets and enforce them

Ask for Core Web Vitals targets, and make sure marketing scripts do not break them. Google’s published “good” thresholds, measured at the 75th percentile of real-user visits, are:

A budget nobody checks is a wish. Lighthouse CI can fail a build when a page exceeds one, which turns “please keep it fast” into a rule that applies equally to your code and to any tag the agency adds:

[{"path":"/*","resourceSizes":[{"resourceType":"script","budget":170},{"resourceType":"image","budget":500}],"timings":[{"metric":"largest-contentful-paint","budget":2500}]}]

Sizes are in kilobytes and timings in milliseconds. Route every new tracking or advertising tag through code review and measure its cost before it ships.

6. Decide who may crawl your content

AI-generated answers favor content that is clearly structured, factual, and easy to attribute. In practice that means descriptive headings, concise answers near the top of a page, accurate structured data, server-rendered content, and a deliberate decision about which crawlers may access your site. That decision lives in robots.txt, and it is an engineering and business call, not a default:

# robots.txt: allow general crawling, restrict one AI crawler to public contentUser-agent:*Allow:/User-agent:GPTBotDisallow:/account/Disallow:/internal/

Check the documentation of each crawler you care about for its current user-agent name, since these change. If a vendor promises AI search visibility, ask exactly what they will change on the site and how they will measure the result. The field is young and claims are easy to make.

A Composite Example: The Silent Migration

The following scenario is illustrative, not a real client story, but it combines problems that appear again and again. A team redesigns its site and changes URLs from /services/seo-audit to /solutions/audit. The redirect map covers the top 50 pages, so the launch looks fine. Three weeks later, organic traffic is down by a third. The cause is a long tail of 800 blog and resource URLs with no redirects, plus a CDN rule that rewrites trailing slashes and turns every single redirect into a chain of two hops.

Both problems would have been caught by the checks above: exporting every indexable URL from the sitemap and server logs rather than only the top pages, and running the redirect verification script against staging. The lesson is that migration work is mostly verification, and verification can be automated.

Questions to Ask Before You Start

• Which parts of the site will you want to change, and who implements those changes?
• How do you handle staging, version control, and code review for site changes?
• What will you track, and will we own the analytics and ad accounts?
• How do you protect existing rankings during a redesign or migration?
• Can you show case studies with real numbers in a similar situation?

Red Flags

• Guaranteed rankings or fixed-timeline promises.
• Requests for full production admin access with no staging process.
• Vague answers about link-building methods.
• No access to your own analytics or ad accounts.
• Tags or scripts added directly in production, outside code review.

Final Thoughts

The best collaboration is the one that fits your stack and your team’s way of working. Put the agreements above in writing, automate the checks that can be automated, and treat marketing changes like any other change to the product: reviewed, tested in staging, and measured after release. When engineering and marketing share the same process, the results tend to follow.