Key takeaways
- Check the changed URLs and shared templates after every release rather than running an undirected full audit.
- Verify live status, redirects, canonical, visible content, links and contact action before waiting for Search Console.
- Keep a release log so a later traffic change can be matched to the exact date and affected pages.
Website maintenance includes protecting the pages people and search engines already use. A content update, plugin change or redesign release can alter URLs, headings, links, canonical tags or page output. The risk is often accidental and localized. A short check after each change makes those failures easier to catch.
This checklist is for the person maintaining a business website. It complements a one-off complete SEO audit and the redesign launch checklist. Use it for ordinary releases and expand the scope when a major migration changes many URLs.
Table of contents
Start with the release and affected URLs
Before testing, write down the release date, what changed, and which URLs or templates are affected. If a header, footer, service template or routing rule changed, sample several page types rather than only the edited page. Keep a pre-release URL list for important service pages. A small maintenance log can contain: date, release, old URL, new URL, tester, result and follow-up owner.
Choose checks according to the change. A copy edit needs content and link review. A route change needs redirects and sitemap review. A design-system change needs mobile readability and interaction checks. A server or framework change needs status and rendered-content checks. This makes maintenance proportionate rather than ceremonial.
Run the live-page checks
- Status: open the changed URL and confirm it returns the intended page, not a blank screen or an error masquerading as 200.
- Redirect: if the address changed, test the old URL and follow it to the closest relevant new page.
- Indexability: confirm that a public canonical page does not have an accidental
noindexor robots block. - Canonical and sitemap: check that the preferred URL is consistent and the sitemap lists current canonical pages.
- Main content: read the title, H1, introduction and service details as a visitor; verify essential text appears in the rendered page.
- Links: click important menu, contextual and contact links; look for broken or outdated destinations.
- Mobile and action: use a phone-sized view and complete the enquiry path.
Google's Search Essentials require accessible, indexable content for Search, and its crawl troubleshooting explains why response and rendered-content checks matter. Do these tests on the live release, then record the result.
Check search and performance signals later
Search Console does not update the instant a change deploys. After an appropriate interval, inspect the affected URLs with URL Inspection and compare their Performance data with a comparable earlier period. Look for a page group that stopped receiving impressions, gained new indexing errors or lost relevant queries. Use a page filter before attributing a sitewide change to one release.
For performance-sensitive changes, record a baseline and test representative mobile pages with PageSpeed Insights or field data where available. Look at actual user experience, not only a single synthetic score. Google's Web Vitals guidance describes the main loading, responsiveness and visual stability measures. A performance check is most valuable when the release added large images, scripts or layout changes.
Use a release log that leads to action
| Release item | Example record | Owner |
|---|---|---|
| Changed URL | /old-service/ redirects to /services/current-service/; final response works. | Developer |
| Changed template | Three sampled service pages show visible H1, service details and contact link on mobile. | Editor + tester |
| Indexing check | Canonical and robots directives match the intended public URL. | SEO reviewer |
| Follow-up | Recheck affected pages in Search Console after Google revisits them. | Site owner |
These are illustrative log entries, not a claim about a real project. If a check fails, note the exact URL, expected behavior, observed behavior and person responsible. Retest the fix after deployment. A checklist without a named follow-up is only a record of the problem.
When should maintenance become a full audit?
Run a broader audit when a site moves domain, changes many URLs, replaces its content management system, loses visibility across sections, or has repeated release failures. Google's site-move documentation provides a larger migration process for URL changes. A major redesign also needs its own prelaunch plan; routine post-release checks cannot replace a URL map and staged validation.
For normal updates, make the maintenance process repeatable. The goal is a working site and clear evidence of what changed. If the team needs ongoing help with code, content, performance and search checks, review the website maintenance service and decide which responsibilities belong in the monthly scope.
Sources and further reading
Need ongoing website maintenance with a clear record of what was checked?
Get in touch