Custom code (head and body)
The Code tab in Page settings stores third-party snippets in tagsAndScripts. Use it for scripts or tags that do not have a dedicated Atomicat setting.
Atomicat supports these code slots:
- Tags and scripts at the top of the
<head> - Tags and scripts at the bottom of the
<head> - Tags and scripts at the top of the
<body> - Tags in
<footer>(footer)
The placeholder asks you to paste script-based snippets including the <script> tag. For vendor snippets, paste the full official snippet instead of only the JavaScript body.
Recommended placement​
| Slot | Use for |
|---|---|
Top of <head> | Critical verification tags or scripts that a vendor explicitly requires before other head content. In the current UI this slot may only appear when existing top-head code is present. |
Bottom of <head> | Analytics, verification, styles, or scripts that should load in the head but do not need to be first. |
Top of <body> | Body-opening tags, noscript fallbacks, tag-manager body snippets, or scripts that must run near body start. |
| Footer | Scripts that can load after page content, chat widgets, lightweight widgets, or non-critical vendor code. |
Prefer Atomicat's dedicated settings when they exist. Use Pixel for Facebook Pixel and Features for Back Redirect instead of duplicating those scripts in custom code.
Validation and security behavior​
When you save Page settings, Atomicat checks custom code before applying the settings:
<script>open and close counts must match.<style>open and close counts must match.<noscript>open and close counts must match.- Partial tags at the end of the textarea are rejected with a clear error.
- Redirect-injection patterns detected as malicious code are blocked. Atomicat reports the page URL and field name internally, shows an error, and can reload the page.
Atomicat validates the code fields during save and can block malformed tags or suspicious redirect behavior. If a field is rejected, simplify the snippet and add scripts one at a time until you identify the issue.
Product suggestions while pasting​
While typing or pasting, Atomicat can show suggestions:
- If the snippet looks like Facebook Pixel base code because it contains
fbqandfbevents, use the Pixel tab instead. - If the snippet looks like a Back Redirect script because it contains
history.pushState,location.href, andpopstate, use Features > Back redirect instead.
These suggestions help avoid duplicate pixels, duplicate redirects, and harder-to-debug custom script conflicts.
Best practices​
- Only add scripts from trusted vendors.
- Prefer official install snippets and update them when vendors change requirements.
- Avoid loading the same tag in multiple slots unless you have a documented reason.
- Do not paste checkout, redirect, or tracking scripts from unknown sources.
- Keep a record of which vendor owns each snippet because the Code tab stores raw text, not vendor metadata.
Testing notes​
- After saving, reopen Page settings and confirm each code area still contains the expected snippet.
- Publish or open the final URL and use browser developer tools to confirm tags appear once and in the intended location.
- Check the browser console for syntax errors and blocked requests.
- For analytics and pixels, verify in the vendor's debugger or events dashboard. A snippet appearing in the page source does not prove the vendor received an event.
- If a save is blocked, remove all custom code, add one snippet at a time, and save after each addition to identify the failing snippet.
Frequently asked questions​
Why does Atomicat warn me when I paste Facebook Pixel code?
The Code tab detects common Pixel snippets and suggests the Pixel tab because Atomicat can manage pixel IDs, events, and server-event options there. Raw Pixel code can duplicate events or bypass those controls.
Why does Atomicat warn me about a back redirect script?
Back redirect has a dedicated setting in Page features. Using the feature keeps redirect behavior visible in Page settings and Page Summary instead of hiding it inside raw code.
Can I add CSS in these fields?
<style> blocks are supported but validated for balanced tags. Prefer the builder's style controls for normal design changes and use raw CSS only when a vendor or advanced layout requires it.
Does custom code run the same in builder preview and on the published page?
Not always. Builder preview runs inside an iframe and may differ from the live domain. Always test the published URL for tag firing, redirects, cookies, and third-party script behavior.