Website / SEO Specialist Responsibilities & Expectations

Website / SEO Specialist Responsibilities & Expectations

Last Updated: June 2026 Version: 1.0 Owner: Website / SEO Specialist

This is the high-level role view for Jakob’s website and SEO specialist lane. Use it as the pinned job description, expectation reference, and onboarding standard for technical website, launch, SEO, and implementation work.

---

What

The Website / SEO Specialist owns the technical execution layer where Tekton’s client websites, search visibility, tracking, and launch quality meet.

This role turns client requests, SEO strategy, site audits, design direction, and internal tickets into shipped, verified work. It covers Astro and Cloudflare site implementation, technical SEO fixes, page updates, schema and tracking support, visual QA, launch readiness, and completion evidence.

The specialist does not own every client conversation by default. The CSM owns the client-facing loop unless Nick assigns it elsewhere. Jakob owns the technical answer, the production-quality implementation, and the proof that the work is ready to communicate.

A ticket is not complete because a change was made. It is complete when the change is verified, evidence is attached, risk is called out, and the next owner can safely close the loop.

Who owns it

Primary owner: Website / SEO Specialist Current assignee: Jakob Client-facing owner: CSM unless Nick assigns otherwise Escalation owner: Nick or Operations when scope, billing, DNS, indexing, ads, account ownership, or launch timing creates risk

The Website / SEO Specialist is accountable for the technical truth. The CSM is accountable for the client hearing that truth clearly and on time.

---

Core responsibility

The Website / SEO Specialist protects the quality of Tekton’s delivery surface.

That means:

1. Making site changes safely from source control, not one-off live edits.
2. Preserving site styling, conversion intent, tracking, and SEO structure.
3. Validating work in the browser before handing it back.
4. Separating implementation facts from assumptions.
5. Giving the CSM or Nick clear completion notes with links, screenshots, and remaining risks.
6. Escalating approval-sensitive changes before touching DNS, indexing policy, canonical rules, redirects, ads, billing, or account ownership.
7. Keeping GitHub, Cloudflare, TaskTracker, and client-facing status aligned.

The role is not just “make the edit.” It is implementation, QA, evidence, and clean handoff.

---

Daily required habits

Morning production sweep

Before starting new site work, Jakob checks active website and SEO tasks for:

1. Items blocked by access, missing copy, missing assets, or unclear scope.
2. Tasks waiting on QA or client approval.
3. Failed builds, failed deployments, or broken previews.
4. Site changes that need CSM closeout.
5. Client-risk items involving broken forms, phone numbers, tracking, redirects, rankings, or page visibility.

Change-level verification

Every website or SEO implementation task needs verification before handoff.

Minimum evidence:

• what changed
• where it changed, with URLs or file paths
• how it was checked
• whether build passed
• whether browser QA passed
• any risk, dependency, or follow-up still open

End-of-day handoff

If active work is not finished, leave a status note in the task or operating thread:

Open item: [client/site], [what changed or is blocked], [current status], [who owns next step], [what is needed to finish].

Silent partial work creates client risk. If the site lane is not done, the next person should know exactly where it stands.

---

Standard workflow

1. Confirm the request, source, client, affected page, and definition of done.
2. Check the current site or repository state before changing anything.
3. Work on the correct branch or approved edit path.
4. Make the smallest safe change that solves the issue.
5. Run the build or local verification required by the repo.
6. QA the affected route in browser-width contexts that matter.
7. Check tracking, forms, phone links, CTAs, and SEO-sensitive tags when relevant.
8. Add completion notes with evidence.
9. Move the task to in_review or the approved closeout stage instead of silently marking it complete when CSM follow-up is required.

---

Approval boundaries

Jakob can own website and SEO implementation work, but some actions stay gated.

Do not perform these without explicit approval from Nick or the approved owner for that lane:

• DNS changes
• registrar changes
• domain ownership transfers
• live indexing or noindex policy changes outside the approved task
• canonical or redirect strategy changes that affect live traffic
• ads, budgets, pixels, or campaign changes
• billing, refunds, discounts, package changes, or contract promises
• client-facing email or SMS sends
• account ownership or permission changes outside Jakob’s approved GitHub website lane

When in doubt, prepare the exact change, evidence, and risk summary, then ask for approval before pushing it live.

---

Client-facing handoff standard

The Website / SEO Specialist should give the CSM a client-safe update, not raw internal notes.

Good handoff:

Fixed the broken estimate button on the homepage and service pages. Verified desktop and mobile. Build passed. Tested the button opens the GHL form on /, /services/, and /contact/. Suggested client update: “The estimate button issue is fixed and tested on the main pages.”

Bad handoff:

Button fixed.

Good handoff:

Technical SEO cleanup is complete for the new service page. Title, meta description, H1, internal links, schema, and canonical were checked. Build passed. Suggested client update: “The page is now published with the SEO basics in place. We’ll keep monitoring performance in the next reporting cycle.”

Bad handoff:

SEO done.

---

Definition of done for the role

The Website / SEO Specialist role is working when:

1. Site and SEO tasks are not left in vague status.
2. Client-risk items are escalated quickly.
3. Builds and browser checks happen before handoff.
4. CSM receives enough evidence to close the client loop.
5. GitHub, Cloudflare, TaskTracker, and wiki instructions stay aligned.
6. Live changes are not made outside the approved boundary.
7. Nick does not have to reverse-engineer what happened after a task is marked done.