The redesign is nearly finished when someone notices that a high-value service no longer has its own page. The developer can restore it, but the change affects the menu, layout, copy, and testing.
That is a project-sequencing problem. The service decision needed to happen before the team treated the page list as final.
Bring the right decisions forward
Google’s guidance on hiring SEO help identifies a redesign or new site as a useful time to involve an SEO. The practical reason is that search, content, and site structure affect decisions other people will build on.
Use this planning table before approving the project schedule:
| Stage | Decision due | People who need to resolve it | Cost of finding it late |
|---|---|---|---|
| Scope | Which existing pages still perform a business job? | Business owner, marketing, SEO | Deleted pages must be restored |
| Templates | Which offers need different information? | Service owner, writer, designer | Finished layouts need rework |
| Build estimate | Are URLs, CMS, domain, or connected systems changing? | Project owner, developer, SEO | Migration work appears outside the estimate |
| Launch approval | Who can resolve a failed release check? | Developer, content owner, approver | The team finds issues without a decision-maker |
| After launch | Who handles defects and ongoing improvements? | Project owner and support provider | Findings sit outside anyone’s active scope |
This is an example responsibility structure. Use the roles your business actually has rather than creating a committee for each row.
Separate different offers before choosing the layout
Imagine a company sells both emergency repair and annual maintenance. The repair buyer needs urgency, coverage, and a contact path. The maintenance buyer may need plan scope, exclusions, and scheduling details.
Resolve those differences before insisting that every service page fit the same short template. The design can stay consistent while allowing enough room for each buying decision.
That discussion is easier while layouts are sketches than after the team has approved finished pages.
Define what “redesign” includes
A visual refresh, a CMS replacement, and a domain move involve different work. Ask which changes are necessary for the business outcome and which can happen later.
Google’s site-move guidance recommends changing major elements separately where practical. The team also gains a clearer explanation of what changed if a problem appears.
Put release checks in the plan, not in someone’s spare time
Reserve time and people to respond to failed checks. Our redesign preservation checklist covers the URL and content checks themselves; the project plan needs to say who acts on the findings and who can delay a release.
Separate fixing a launch defect from commissioning a new content program. Both may be necessary, but combining them under “SEO later” makes responsibility hard to pin down.
If a redesign is approaching, The Ops Guide can help connect SEO with the project plan before the expensive decisions are locked in.
