Technical, on-page and off-page SEO are useful planning categories, not a universal division of responsibility. A real issue can span several workstreams. Use this guide to decide which evidence, people and deliverables a website problem requires.
01Begin with the symptom
Describe a visible problem before selecting a service label. A page missing its main content in initial HTML is different from a clear page answering the wrong question. Collect enough evidence to decide what to inspect next, rather than ordering every available SEO task by default.
- Name the affected page or template
- Record current and intended behavior
- Separate observed facts from hypotheses
02Technical work examines delivery and access
A technical review can investigate crawling, response behavior, rendering, canonicalization and site structure. Its useful output is a reproducible finding or implementation ticket, with dependencies and acceptance checks. This does not mean every technical recommendation includes development work in the same engagement.
- Define the inspection sample
- Identify development and hosting owners
- Request verification steps with each finding
03On-page work examines the answer
On-page work connects the page purpose with titles, headings, main copy and internal links. Start by checking whether the reader’s actual question is answered. A metadata rewrite cannot substitute for missing useful content or justify a second page serving the same intent.
- Review the main answer and supporting detail
- Check overlap with existing URLs
- Keep metadata consistent with the body
04Off-page work needs evidence and boundaries
Off-page discussions often concern how a business is referenced elsewhere. Evaluate the relevance and nature of any proposed activity, who owns it and what can actually be verified. Do not accept a volume of links or a third-party score as an automatic business result.
- Ask how a placement is obtained
- Request the actual published reference
- Review quality and risk before approving activity
05Coordinate the workstreams
An illustrative launch can require a content owner to write a guide, a developer to publish complete HTML and a marketer to connect relevant existing pages. Assign those actions separately. A shared release checklist avoids blaming one person for an implementation dependency outside their agreed role.
- Map each action to an owner
- Record dependencies and inputs
- Separate delivery from outcomes
06Agree the smallest useful next step
Choose a bounded work package based on the evidence: a diagnostic sample, a specific page improvement or a development fix. Define what the team will receive and how completion will be checked. Review authorized search and inquiry data later to decide whether the next investment should change.
- Specify deliverables and exclusions
- Define a release or handoff check
- Keep measurement assumptions visible