Rêyeke aramtir ji bo nirxandina nûvekirineke temayê

An update review needs a clear starting point. Without a record of customisations, it is easy to spend the entire review wondering whether a difference is intentional.

Keep a short change record

Describe custom components, edited templates and styling decisions in plain language. Include their purpose, not just their filenames. That record should help a developer understand why a change exists and what behaviour needs to survive the update.

Use representative journeys

Choose a small set of useful paths through the site: browsing a category, reading a detail page, using navigation and submitting a form. Include a narrow screen and keyboard navigation. Review actual content, including a deliberately long heading, rather than relying on an idealised sample.

Make the decision explicit

Record the differences you found and whether each one is accepted, fixed or deferred. Preserve a recovery option until the updated site has been checked. A review does not need to be elaborate to be valuable; it needs to be repeatable and understandable to the person who handles the next update.