How to Update a Website: 10 Steps from Draft to Live

If you only need to correct text or an image, open the existing page in your site’s editor, make the correction, review its preview and use the platform’s publish or update action. Check the live page afterward. For shared templates, integrations, software or URL changes, work through the fuller process below.

1. Define the update and its expected result

Write one concrete reason for the change: correct opening hours, explain a new service, repair a phone menu, update a supported integration or replace a screenshot that no longer matches the product. “Make the site modern” is too broad to tell whether the work succeeded.

State who will edit, who can approve the facts or design, and who can publish or recover the site. Keep a short change record with the affected URLs, intended outcome, owner, test and publication status. Separate an urgent correction from optional improvements so the urgent work does not wait for an entire redesign.

2. Audit the current pages and capture a baseline

List the affected pages and any shared elements: header, footer, navigation, article template, product card or form. Record what currently appears and what should change. Check important facts against their current primary sources, including dates, product behavior, prices, contact details and screenshots.

Use search and analytics data to choose useful work, then inspect the actual page and task. A drop in impressions or conversions is evidence to investigate, not proof that an old-looking design caused it. Note the baseline period, affected queries or pages and relevant recent releases. The website audit scope guide explains how to define an investigation and its deliverables.

Keep the material that already answers the reader’s question well. Remove repetition, repair inaccurate claims and add the missing explanation, example or evidence. Google’s people-first content guidance specifically warns against changing page dates or adding/removing material merely to appear fresh. A changed year in the heading is not a substantive update.

3. Confirm what you can restore before editing

Choose a recovery method that matches the site. A CMS revision, a website snapshot, a source-code version and a database backup cover different things. Confirm what is included, where it is kept, who can restore it and whether recovery has been verified. A downloaded copy that cannot be restored is not a useful plan.

For a self-hosted WordPress software upgrade, the official upgrade instructions include backing up the database and files and checking that backups are usable. Follow the current workflow for your host and version rather than importing a generic database-overwrite instruction into every site.

A rollback may reverse design or code while other data continues changing. Restoring an old database over an active site can discard newer records. Agree the recovery boundary and who handles data reconciliation before a change that could need it. For a minor copy edit, a saved revision and recorded original content may be enough; the recovery process should fit the change.

4. Use the editor that owns the content

First identify whether the page is static content, a shared template or a CMS item. Editing the template to correct one article can accidentally change every article. If a developer manages the site, request a focused change through that project’s normal review and release process rather than editing generated files that the next deployment will replace.

For a Grigora AI-built site: open its AI Editor and describe a specific change, naming the page or element and supplying the correct text or asset. Review the generated result, use the desktop/tablet/phone previews and open the standalone preview to test navigation. Publish after approval, then inspect the public URL. The current AI Editor walkthrough explains these controls.

On the Contact page, replace the opening hours with “Monday–Friday, 09:00–17:00”. Keep the address and existing form. Check the layout at phone and desktop widths, and show the updated preview for review.

Grigora’s AI version-history guide explains previewing an earlier snapshot and restoring it as the working draft. Reviewing a historical version does not itself change the draft; restoring a draft and publishing a public version are separate actions. Do not assume a design snapshot reverses orders or every connected backend record.

For a Grigora classic template site: use the Site Editor to select and change the relevant blocks, preview different device sizes and publish the approved result. Use the appropriate CMS entry editor for an individual post. AI Editor instructions and classic block-editor controls are different workflows.

For exports, check the format and limits rather than assume an offline copy reproduces a hosted application. Grigora’s current export specification distinguishes rendered visual-site pages/assets from saved AI source/assets; hosted CMS, commerce and other backend services are not recreated in the ZIP. Confirm any additional data you need with the platform before relying on an export as your recovery method.

5. Refresh text, images and other media together

• Text: Correct factual errors, remove obsolete offers and make the next action clear. Preserve useful original explanations and maintain appropriate sources for consequential claims.
• Images: Replace screenshots that no longer match the interface. Check accuracy, permission, useful crop, loading, descriptive alternatives and diagram legibility at phone width. Remove obsolete text embedded in images too.
• Video and downloads: Review spoken or printed instructions, captions, linked files and dates. A current paragraph does not repair an old tutorial that still shows the wrong workflow.
• Metadata: Keep the title, description, social preview and structured information consistent with the revised page. An accurate summary helps readers understand the result; it does not guarantee more clicks.

Use a real modification date when the content has materially changed, while preserving an accurate original publication date where shown. Do not claim you tested a product, interviewed a source or measured an improvement unless that work actually happened.

6. Preserve URLs and indexing intent

A normal content refresh usually does not need a new URL. If the current address still describes the page, retain it so existing links keep working. When a move is necessary, map the old URL to the relevant new destination, use an appropriate permanent redirect, and update internal links, canonical references and the sitemap.

Google’s site-move guidance recommends a URL mapping and monitoring both old and new addresses. It also warns that search visibility can fluctuate while changes are processed. Avoid sending unrelated deleted pages to the homepage; genuine removed content may need an appropriate missing/gone response.

Check that intended public pages did not inherit a staging noindex setting, an incorrect canonical or blocked assets. Conversely, keep intentionally private or excluded pages out of public indexing. The sitemap guide explains that the desired page set matters more than submitting every URL. Do not remove a protection simply because a tool reports it as a warning.

7. Review layout, mobile behavior and accessibility

Preview the change on representative desktop, tablet and phone widths, including the areas just around a breakpoint. Try a long heading, a narrow menu and real content. Check for clipped labels, overlapping controls, excessive empty space, distorted images and tables that push the whole document sideways.

Use keyboard navigation, visible focus, readable text, clear field labels and meaningful image/media alternatives as part of the review. A visual refresh should preserve the ability to use the site. W3C’s preliminary accessibility checks are a starting point, not a complete assessment or proof of conformance.

A responsive preview is useful but does not reproduce every physical device. The mobile troubleshooting guide helps separate viewport, browser, cache and content differences. Record the actual browser/device coverage instead of describing one preview as testing every screen.

8. Apply software and integration updates deliberately

For software you maintain, review the vendor’s release and compatibility information, test the relevant update in a suitable environment and check dependent themes, extensions, custom code and integrations. Follow supported upgrade paths. An urgent security fix may need a faster response than a routine visual refresh, with recovery and verification appropriate to the situation.

On a managed builder, the provider generally maintains the hosting platform; your responsibilities still include accurate content, authorized access, suitable integrations and testing your site’s behavior. A valid HTTPS connection protects data in transit but does not establish that every application feature is secure. Do not add unrelated security products or change access controls merely to make a general update checklist look complete.

Keep the test environment separate from live side effects. Confirm that test forms, payments, notifications and other integrations use the intended test setup. A staging address is not automatically private or unindexable simply because it is called staging.

9. Test the draft against an acceptance checklist

Test the changed behavior and the shared components it touches. A page can look correct while its form fails, its data is wrong or its important links lead elsewhere. Record passed, failed, blocked and untested items, and resolve important failures before publication. The website bug-finding checklist provides a more detailed task and evidence workflow.

For a small text correction, the relevant checks can be short. For a shared template or checkout change, expand coverage to representative pages and states. Keep performance diagnostics comparable and separate lab scores from real-user data; changing a score is not the only acceptance criterion for a functioning website.

10. Publish, verify live and keep a review schedule

Publish the approved change through the site’s normal workflow and record the version and time. For a larger release, choose a window when someone can check the result and respond if an important failure appears. A low-traffic period is useful only if the required people and recovery process are available.

Open the actual public URL, including the custom domain where used. Confirm the right content, important images, navigation and affected task. A saved draft, successful preview or completed deployment message is not a substitute for this live check. If stale content appears, distinguish browser/CDN caching from an unpublished draft, wrong environment or failed release before repeatedly editing the page.

If a critical failure appears, use the agreed recovery or targeted correction, preserve newer data and verify the public result again. Review errors and relevant analytics over comparable periods afterward. Traffic, search demand and tracking changes can move the numbers; do not attribute every increase or decrease to this one release.

Set review triggers as well as reminders: changed prices or hours, a product release, broken journey, expiring asset permission, a new dependency issue or an affected search query. Assign an owner and next review date to important pages. Routine review can be scheduled, but urgent factual errors or security updates should not wait for a quarterly content sweep.

Website update FAQs