Documentation last updated May 29, 2026
Adapter and release status
Hugo remains a dedicated issued package lane with prefilled config values rather than a Platform Core subpath.
Current version
0.1.23
Delivery lane
Issued ZIP
Compatibility notes
Hugo remains a dedicated issued package lane with prefilled config values rather than a Platform Core subpath.
Key rollout changes
1. Use the dedicated `cookiezy-hugo-package.zip` artifact.
2. Copy partials, static assets, and example config into the Hugo project.
3. Keep locale routes and policy pages aligned before publish.
Hugo adapter: dedicated package rollout
Use this guide when you are shipping Cookiezy through the dedicated Hugo package rather than Platform Core. The package already carries the issued licensing values, example config, and static assets.
- • Generate `cookiezy-hugo-package.zip` from Downloads.
- • Copy the partials, static assets, and example config into the Hugo project.
- • Keep locale routes and policy URLs aligned before publish.
- • Register the production hostname in billing, then validate banner, settings reopen, and cookie audit behavior.
Copy the issued package into the Hugo project
The dedicated Hugo artifact already contains the shared runtime assets, Hugo partials, and an example config scaffold with the issued site key and verification URLs.
Code snippet
Package: cookiezy-hugo-package.zip
Copy into project:
- layouts/partials/cookie-consent/
- static/js/
- static/css/
- examples/config/Align config, locale routes, and policy URLs
Open the example config scaffold and carry the issued values into your real Hugo config. If the site is multilingual, keep `defaultLocale`, `localeRoutes`, and per-locale policy URLs aligned before launch.
- • Copy the issued `siteKey`, `verifyUrl`, and `billingUrl` exactly and do not wrap them in extra escaped quotes.
- • Make sure each locale points to the correct cookie policy page path.
- • Keep the same locale map between the banner runtime and the published Hugo routes.
Validate the live Hugo site
After publish, test the visitor-facing runtime on the real hostname.
- • Banner appears on first visit.
- • Reject optional keeps optional integrations blocked.
- • Accept all unlocks the categories you configured.
- • Settings reopen works from the footer or policy page.
- • Cookie audit renders on the policy page and stays aligned after consent changes.
- • Runtime verification returns `allowed: true` for the registered hostname.