Who is a Content & SEO Engineer FTE for?
A Content & SEO Engineer FTE is for teams running a Next.js site without a content management system, where publishing an article means committing a file. It is common among developer-led companies whose marketing site lives in the same repository as the product.
Those teams often have the technical setup that makes publishing easy and no one whose job it is to do it. This role fills that gap by working the way the team already works: through pull requests.
How does an article become a pull request?
Each week the FTE proposes articles against search intent, and once the plan is approved it drafts each one as SEO-ready MDX in a branch and opens a pull request. The pull request contains the article, its metadata, and its structured data, ready for the existing build.
The team reviews it the way they review any change: reading the diff, requesting changes, and merging when it is right. There is nothing new to learn, which is the reason the role fits developer-led teams so naturally.
Why is publishing as a merge safer?
Publishing as a merge is safer than publishing through a dashboard because a merge is reviewable, attributable, and revertible. The approval is the merge itself, made by a named person, and reverting a bad article is a revert commit rather than a support request.
It also keeps the audit trail where engineering teams already keep it. Who approved what, and when, is answered by the repository history rather than by a separate log.
- Plan: articles proposed against search intent, approved before drafting
- Draft: SEO-ready MDX with metadata and structured data, in a branch
- Review: a pull request the team reads like any other change
- Publish: the merge, by a named person, revertible if needed
How does it decide what to write?
The Content & SEO Engineer FTE plans against search intent rather than keyword volume alone: which questions the site's users are asking, which are unanswered, and which existing articles are decaying. Each proposed article carries the intent it targets and the reason it was chosen.
That reasoning is in the proposal so the manager approves the strategy, not just the output. A plan that says why these five articles, why now, and what the alternatives were is a plan that can be argued with.
How does it measure and maintain?
After merge, the FTE measures impressions and rankings per article through read-only Search Console access on a schedule, and queues refresh proposals for articles that begin to decay. A refresh arrives as another pull request, with the diff showing exactly what changed.
To start, it needs repository access with permission to open pull requests, the brand rules and topics to cover first, and read-only Search Console. It does not need merge rights; the merge stays with the team unless the team chooses to grant it later for a specific class of change.
What does it cost, and what does it need from your engineers?
A Content & SEO Engineer FTE consumes tokens for planning, drafting, the fact gate, and its brief, bounded by its per-FTE budget and visible daily in the morning brief; approving and merging cost nothing. What it needs from your engineers is small and one-off: a connection to the repository with permission to open pull requests but not to merge, scoped to that property and revocable from the workspace, or, for a site that is not a repository, the publishing endpoint package installed once in the customer's own Next.js site.
After that, the engineers' involvement is the pull request review they already do for every other change, and the FTE's pull requests are formatted to that convention: the content in the repository's own format, the sources attached in the description, and the fact-gate result stated. Nothing publishes without a merge, which is a decision by the person with merge rights. The content lead approves the draft in the workspace; the engineer merges the pull request; the audit trail records both, and the repository's history records the second a second time.