GuideResearch notePreview

15 questions to ask before starting a corporate website redesign

A planning frame to complete before writing a brief or approaching agencies.

Direct answer

Before starting a web sitesi yenileme project, clarify the business goals, the priority users, content ownership, CMS expectations, integrations, accessibility, privacy and cookie experience, SEO and AI discoverability, launch approach and the post-launch operating model. Most redesign overruns are decisions that were deferred, not work that was underestimated.

Answer these before the brief, not during the project

A brief written after these questions produces comparable proposals. A brief written before them produces proposals that differ mainly in how much they assume — and assumptions surface as change requests once the work is underway.

The fifteen questions

  1. 01

    Why now?

    Name the trigger honestly: a leadership change, a brand refresh, an unmaintainable stack, a compliance expectation or a commercial gap. The trigger determines what success means and which trade-offs are acceptable.

  2. 02

    Which business outcome must change?

    Lead quality, application completion, recruitment volume, investor self-service, support deflection. If no outcome is named, the project will be evaluated on taste.

  3. 03

    Who are the priority users?

    Most corporate sites serve customers, candidates, investors, journalists and partners at once. Rank them. Unranked audiences produce homepages that address everyone and convince no one.

  4. 04

    Which journeys matter most?

    Identify the three to five paths that carry commercial or operational consequence, and design the project around them rather than around the page inventory.

  5. 05

    What content is outdated or missing?

    Run a content inventory before scoping. Redesign projects routinely discover that the real constraint is content production capacity, not design or engineering.

  6. 06

    Who owns content after launch?

    Named owners per section, with time allocated. Content ownership left unassigned is the single most reliable predictor of a site that looks dated within two years.

  7. 07

    What must be manageable in the CMS?

    List what editors must change without a developer, and what should deliberately stay locked. Both lists matter; unlimited flexibility degrades templates as quickly as excessive rigidity frustrates teams.

  8. 08

    What integrations are required?

    CRM, marketing automation, careers, investor data, search, translation and analytics. Integration discovery late in a project is a common cause of scope expansion.

  9. 09

    What accessibility expectations and governance apply?

    Define the target alignment, who reviews it, and how it is maintained after launch. Accessibility added at UAT is expensive; accessibility designed into components is not.

  10. 10

    What cookie and privacy experience is required?

    Consent interface behaviour, pre-consent tag policy, preference granularity and who governs tags after launch. Decide this before templates are built.

  11. 11

    What SEO and GEO visibility is expected?

    Existing rankings, URL migration, structured data and entity consistency. A web sitesi yenileme project without a migration plan can lose visibility that took years to build.

  12. 12

    What performance targets matter?

    Set budgets in numbers, on the templates that carry traffic, measured on the devices and networks your audience actually uses.

  13. 13

    How will approvals work?

    Number of reviewers, decision rights, response times and escalation. Approval design is project-schedule design.

  14. 14

    What is the maintenance model?

    Who keeps the site fast, accurate, accessible and current after launch, with what budget and what response expectations.

  15. 15

    How will change requests be prioritised after launch?

    Agree the intake, prioritisation and release rhythm before go-live. Teams that decide this afterwards usually default to quoting each change individually.

Why skipping these questions creates cost and scope problems

Deferred decisions do not disappear; they relocate to the most expensive phase of the project. Content ownership left open becomes a launch delay. Integration discovery left to development becomes rework. Accessibility left to UAT becomes component surgery. Migration left to the release week becomes lost search visibility.

There is also a governance effect. When a project has no recorded answers, every review meeting re-opens settled ground, because no one can point to the decision. The cost shows up as elapsed time rather than as invoices, which makes it easy to miss and hard to recover.

A workable sequence

  1. Write answers to all fifteen questions, marking any that are genuinely open.
  2. Circulate them to marketing, IT, legal and the affected business units for correction.
  3. Resolve the contradictions before scoping — they are the real requirements discussion.
  4. Attach the agreed answers to the brief or RFP as the decision record.
  5. Revisit the record at each phase gate rather than re-litigating decisions ad hoc.

Request a preliminary assessment

A public-signal review of your current site gives the redesign discussion an evidence base rather than a set of opinions.

Request preliminary assessment

Related index dimensions

  • D2 · 10%

    UX & Content Clarity

  • D3 · 15%

    Performance & Technical Health

  • D7 · 10%

    Maintenance & Update Efficiency

  • D8 · 10%

    Digital Operations & Cost Optimization

This guide is educational and based on publicly observable enterprise web patterns. See the methodology.

ShareLinkedInXWhatsApp