SOP: document custom Shopify theme code without breaking the design
How I turn Liquid and CSS changes into a maintenance guide: where they live, what they change, and how to roll back safely.
The problem
An ecommerce theme had accumulated Liquid sections and CSS rules for specific visual needs. The store worked, but every update depended on remembering which snippet controlled a grid, a featured block, or the product page. Without documentation, a small edit could change the entire layout.
The resolution: inventory before editing
I started by duplicating the active theme. That backup is not bureaucracy; it is the fastest way to recover a known state if a test affects the storefront. I then separated changes by location and purpose:
- Liquid sections for content blocks and links.
- Customizer CSS for tightly scoped visual changes.
- Product templates for block order.
- Theme files for shared styles.
For every change, I recorded its exact location, visual purpose, editable parts, and rollback note. A card grid, for example, should say where to replace the image, link, and text; a color rule should say which selector it targets and when not to use it. Maintainers can then update content without interpreting the entire codebase.
Controls that prevented regressions
I tested custom sections on desktop and mobile, especially grids and text over images. Overly broad CSS selectors were limited to the relevant block so they would not affect other theme instances. I also documented dependencies that should not be removed, such as Liquid variables that render product content.
Before publishing, I compared the preview with the active theme and reviewed links, images, hover behavior, and the product page. Documentation is updated with the change; leaving it for later makes it stale quickly.
Apply it to your store
If you inherit a store with custom code, do not begin by changing the most visible snippet. Duplicate the theme and create a minimal inventory of every custom change. Prioritize the ones that affect conversion, navigation, and product pages. For each one, answer: what does it render, where is it edited, what must not be changed, and how do you verify it?
When a block fails, return to the duplicated version, inspect the theme editor for syntax errors, and narrow the issue to one section. This prevents a local fix from becoming a full-site regression.
Reusable checklist
- Duplicate the theme before changing code.
- Record each file or section, purpose, and editable areas.
- Scope CSS to the affected block.
- Keep Liquid variables required for dynamic content.
- Test desktop, mobile, links, and images.
- Compare preview and update the documentation when publishing.