Quick answer
GTM custom-template logging can be restricted to debug or preview mode. Google documents that denied logging permission suppresses logToConsole output without throwing an error. Therefore, a message missing on the live site is not proof that the template failed. Check the published version, logging policy, and actual business outcome separately before enabling more logging.
Confirm that the two tests run the same build
Record the container identifier, published version, workspace changes, and template revision. Preview often evaluates a workspace that is not yet published. If the live site loads another version, different console behavior may simply reflect different code.
Check the actual page and environment too. A staging hostname can have a different container or consent configuration from production. Keep the test page, browser state, and fixture consistent. Do not publish unfinished tracking changes solely to make a diagnostic message appear.
Read the logging permission
Inspect the template's logging permission and determine whether production logging is enabled. Compare that setting with the intended operating policy. For many integrations, suppressing routine console messages on live customer sessions is desirable.
Do not change a broad set of permissions to troubleshoot one missing message. Logging access is distinct from permissions to read data, load scripts, or send requests. A silent log call does not establish which of those other operations ran, and a visible log does not prove they succeeded.
Use a harmless diagnostic marker
When a controlled test needs a marker, use a fixed fictional label such as template_probe_A. Do not log form payloads, email addresses, phone numbers, authorization values, click identifiers, or a full page URL that may contain sensitive query parameters. A helpful debug message can describe a branch without printing the value that selected it.
Agree where diagnostic evidence is retained and who can read it. Browser console output can be captured by monitoring products, screen recordings, support exports, or other scripts. A production logging change can therefore have consequences beyond the person currently looking at developer tools.
Follow execution beyond the console
Check whether the intended trigger occurred and whether the template produced the expected output for the fictional fixture. Then inspect any resulting browser request and the destination's test receipt. Keep these checks independent from log visibility.
If the template returns the correct value and the destination receives exactly one intended event, missing console text may be working as configured. If the request never happens, investigate trigger conditions, data availability, consent, or security policy using their own evidence. Turning on production logging does not fix those underlying conditions.
Environment | build | logging allowed | marker | event outcome
Preview | record| record | record | record
Production | record| record | record | record
Denied path | record| record | record | expected policy
Escalate logging only when necessary
If a live-only problem cannot be reproduced safely elsewhere, define a narrow diagnostic window with the site owner. Specify the non-sensitive fields, affected path, expected volume, retention, and rollback. Prefer a minimal branch marker over dumping arbitrary objects.
After collecting the required evidence, restore the intended logging policy and verify that the marker is no longer emitted where it should be suppressed. Confirm normal event delivery still works. A temporary debugging setting should not become a permanent source of customer-data exposure because the incident was closed in a hurry.
Write an outcome-based conclusion
Record whether the difference came from version mismatch, expected logging restrictions, or a genuine execution failure. Include the evidence for the final event outcome. Avoid a conclusion such as tracking is broken because the console is empty. The useful answer explains which behavior was expected, which failed, and what was changed without expanding access or data collection unnecessarily.
Illustrative diagnostic example. Use your own redacted evidence.One final acceptance check
Check developer-console filters before treating an absent marker as permission evidence. A hidden message level or text filter can conceal output that was emitted correctly. Record the active filter state in the controlled test, while keeping the destination receipt as the stronger evidence of tracking completion.
When to bring in help
Use WordPress tracking and privacy diagnostics when console behavior distracts from a genuine delivery issue. Share the template version, permission setting, and redacted request evidence rather than a full customer-session capture.
Related troubleshooting
For the adjacent diagnostic path, read GTM template permission review. Keep its evidence separate from this test so a change in one component does not hide a failure in another.
Helpful references
GTM template permissions.