How to Improve a Website Without Replacing the Existing Production Company
Tomohiro Iida · Published August 13, 2026 · Updated September 7, 2026
When search visibility or enquiry paths are not working, replacing the production company may seem like the first answer. But the bottleneck may instead be the contract scope, the precision of the request, the approval path, or the lack of post-release verification. Change the operating model before deciding whether the company must change.
This article covers how to divide diagnosis, improvement specifications, implementation, release approval, and post-release observation while keeping the existing production company. It does not compare production companies, explain pricing, or reproduce the fourteen fields of the improvement-specification article.
How to choose an SEO and web improvement partner
B2B website improvement cost and the 90-day roadmap
How to write a web improvement specification
How to protect SEO, AI search visibility, and lead measurement during a website redesign
Conclusion: separate roles and the unit of handoff before changing companies
- Observe: confirm what is happening from public pages, search, measurement, and business information.
- Trace: identify the implementation, configuration, or operating cause.
- Specify: convert the finding into a target URL, change, completion criteria, and verification.
- Execute: the production company or internal team implements and reviews the change.
- Verify: confirm the production state and observe what changes after release.
One company does not have to own every stage. Every stage does need an owner, input, output, release decision-maker, and verification method.
1. Confirm what the existing contract and environment already cover
| Item | Check | Decision |
|---|---|---|
| Maintenance scope | CMS updates, code, incidents, server, and domain | In scope or additional estimate |
| Environment | Production, staging, CMS, repository, and tag management | Where changes and checks happen |
| Release authority | Who merges, deploys, changes DNS, or publishes CMS content | Implementer, approver, and publisher |
| Existing commitments | Monthly work, deadlines, and material handoff dates | Avoid conflicts in the release plan |
| Deliverables | Reports, design, code, release check, and maintenance record | What is handed to the existing company |
If scope is unclear when the specification is handed over, cost and schedule disputes appear at the implementation stage. Narrowing the scope is possible, but record who owns the remaining work.
2. Give every work item a single accountable person
RACI separates the person who does the work (Responsible), the person who is finally answerable (Accountable), the person consulted (Consulted), and the person informed (Informed). Even when several people carry out the work, one person carries the final judgement. Name a role or a person, not only a company.
The table below is a design example for the case where the client’s existing production company writes the code and external support runs the diagnosis. The “owner” labels are illustrative role names; in practice, enter the actual people. This table alone does not change the responsibilities in an existing contract.
| Work or decision | Responsible (R) | Accountable (A) | Consulted (C) / Informed (I) | What is kept on completion |
|---|---|---|---|---|
| Confirming business goals and priorities | Client web owner | Client business owner | C: external support, production company | Targets, priorities, and what is out of scope |
| Quality review of diagnostic evidence | Analyst at the external support | Quality owner at the external support | C: production company, I: client web owner | Target URLs, observation dates, facts and hypotheses |
| Approving the change specification and budget | Client web owner | Client business owner | C: external support, production company | Specification version, scope, acceptance criteria |
| Code implementation and technical testing | Implementer at the production company | Technical owner at the production company | C: external support, I: client web owner | The change diff, test results, known constraints |
| Deciding whether to release to production | Client web owner | Client release approver | C: production company, external support | Release target, permitted scope, rollback conditions |
| Performing the approved release | The person holding production access | Release owner at the production company | I: client web owner, external support | The version actually released and the execution result |
| Technical verification right after release | Verifier at the production company | Technical owner at the production company | C: external support, I: client web owner | Display, link, and measurement check results |
| Enquiry receipt and business acceptance | Client web owner | Client business owner | C: production company, external support | Test receipt, acceptance decision, open issues |
Where one person holds both implementation and technical accountability, record the roles separately anyway. If the contract places the release itself with the client, move R and A on that row to the client side. Any work item with a blank Accountable needs an owner before work starts.
Being technically able to release and being commercially cleared to release are different judgements. Do not collapse code, release, and business acceptance into a single “approved”. Do not build a table in which external support is assumed to perform every step on the client’s behalf.
Record the approved version and the permitted action
Record not just who approved, but what they approved. If the copy or the code changes after approval, re-check whether that change still falls inside the approved scope.
- Target: the pricing page revision
- Approved version: the copy version or code identifier
- Permitted action: releasing the agreed pages to production
- Preconditions: match with the pricing source of truth, Japanese and English parity, pre-release testing
- Release operator: the person named in the contract
- Final release decision-maker: the client’s release approver
- Post-release checks: display, enquiry path, measurement, receipt
- Stop and rollback conditions: pricing mismatch, failure of a primary path
- Result to keep: the version actually released, the time verified, and anything unresolved
This memo is an illustrative way to organise what was approved. It is not a substitute for a signature or a contract. Keep three facts separately verifiable: that the implementer passed technical testing, that the client approved the release, and that business acceptance happened after release. Also distinguish an explanatory correction with no effect on price or scope from an actual change to the contract.
3. Hand over one packet for each issue
- Issue ID and target URL
- Observed symptom and confirmed fact
- Implementation cause and the parts that are still hypotheses
- Proposed copy, structure, code, or settings change
- Allowed and excluded scope
- Priority, owner, deadline, and dependencies
- Pre-release checks and post-release recheck date
- Required permission and the person who holds it
The existing production company should not have to reconstruct the page, scope, priority, and completion criteria from a general request such as “improve SEO”. Use the improvement-specification article for the detailed format; this article focuses on the handoff and decision process.
4. Make meetings decision points, not open-ended consultation
- Kick-off: issue IDs, target and excluded URLs, implementation decision deadline, approver, release date, and launch stop criteria.
- Implementation review: production code or CMS changes, language parity, metadata, canonical, structured data, links, CTA, form, and event regression.
- Post-release review: status, redirects, sitemap, HTML, form receipts, GA4 events, Search Console state, open issues, and next deadlines.
Record not only decisions but also deferred decisions and their reason. Every unresolved item needs an owner and a due date.
5. Reduce friction with three principles
- Do not dictate the implementation method without checking the CMS, framework, and deployment constraints. Fix the goal, facts, target, and completion criteria; let the production company propose the implementation.
- Do not treat the existing company as a competitor. If it owns production, it is the partner receiving search and measurement facts and turning them into a safe release.
- Separate implementation completion from outcome observation. A production HTML change can be complete while rankings, AI answers, and enquiries remain subject to external factors.
6. Diagnose where the work is stuck
| Stuck pattern | First check | Next action |
|---|---|---|
| Many questions about the specification | Target URL, change, and completion criteria | Split into one issue and one URL |
| Estimates differ widely | Whether investigation, implementation, and verification scopes match | Compare scope tables |
| Implementation is postponed | RACI, permission holder, and approver | Create a dated decision item |
| Problems appear after release | Launch-day verification and assigned reviewer | Make the release checklist mandatory |
| Metrics do not move | Baseline, comparison period, and concurrent changes | Separate observation from causality |
| The discussion returns to changing companies | Capability problem or handoff and contract problem | Pilot one issue with shared responsibility |
Frequently asked questions
- Can this work if the production company is not strong in SEO?
- Yes, if the search and measurement side supplies confirmed facts and completion criteria while the production company assesses implementation and impact.
- Does the existing production company need every permission?
- No. Grant each person only the environment and action required, with a duration and removal condition. See the access-design article for GA4, Search Console, CMS, and GitHub.
- Does SIGNAL replace the existing production company?
- Not as a premise. Depending on the contract, the roles can cover public diagnosis, specifications, implementation support, and post-release verification. The implementer and release approver must be explicit for each engagement.
How much access to grant for web improvement
Key takeaways
- Confirm the existing contract, environment, permissions, and release path.
- Divide Observe, Trace, Specify, Execute, and Verify.
- Fix RACI and hand over one issue packet per target URL.
- Use meetings to make decisions and assign deadlines.
- Separate implementation completion from the observation of search and business outcomes.
Public information only. Identify the first issue to hand to the existing production company.
Start the Netsujo SIGNAL free diagnosisDiscuss roles, handoff materials, release decisions, and verification while keeping the existing production company.
Discuss a Netsujo SIGNAL plan