# AZTANDC LLC

- Site: https://aztandc.com/

## AI-Designed Landing Pages, Built Into Your Website (Not Embedded From Somewhere Else)

- Link: https://aztandc.com/articles/ai-designed-landing-pages-built-into-wordpress
- Published: 2026-10-14T19:08:42-07:00
- Author: aztandc

AI tools have made it remarkably easy to design a striking landing page. Describe
what you want, refine it, and in a short time you have something that looks like
it took a team weeks to produce.

The harder question is not how to design the page. It is where the page should live
once it is finished.

## Two ways to publish an AI-designed page

Most teams end up choosing between two approaches:

 * **Host it in the design tool.** The page is built and published in a platform
   such as Ceros or Netlify, then linked, embedded in an iframe, or served from 
   the platform’s own domain.
 * **Build it into your website.** The page is designed with AI, then converted 
   and built directly into your site so it becomes a real page, just like the rest
   of your content.

Both can look great. They behave very differently once the page is live.

## Create it with AI, then we build it into WordPress

You do not have to choose between the creative freedom of AI tools and the practicality
of your own website. Design the page in whichever tool your team prefers, whether
that is Ceros, Netlify or another AI or hosted builder. Once it is created, we take
it and convert it to WordPress so it matches what you created, including the layout,
styling and animation.

We do this with our own AI-assisted workflow. Designers keep their creative freedom
and the ease of using AI, while the finished page becomes a real part of the site.
The benefits are practical:

 * **The AI benefit, without the trade-offs.** You get the speed and creativity 
   of AI design, plus a page that lives in your own website.
 * **A consistent look and feel.** The header and footer look the same as the rest
   of the site, and the page uses the same navigation and forms, so visitors never
   feel like they have left.
 * **Easier edits.** Your team updates the page in WordPress like any other page,
   rather than going back to the design tool.
 * **No externally hosted embed.** There are fewer outside dependencies to manage,
   and the content is part of your own website rather than a frame loaded from somewhere
   else.
 * **More control over tracking and data sharing.** Analytics, tag management, consent
   settings and form submissions can follow the same rules as the rest of your site.
 * **Quick and straightforward to create.** Using AI for the design and the build
   keeps page creation fast without giving up quality.

## Embeds and hosted pages can bring their own tracking and cookies

Whether a page is embedded in an iframe or hosted on the design platform’s own domain,
it is no longer running under your website’s controls. The platform may set its 
own cookies, load its own scripts, or collect its own analytics data. Those may 
not match what your site’s tracking and cookie banner are configured to allow.

That can create several things to deal with:

 * **Cookies and trackers you did not choose.** A third-party page may set cookies
   or use tracking technologies that are not listed in your cookie inventory or 
   covered by your consent categories.
 * **Consent that does not carry over.** A visitor’s choice in your cookie banner
   may not reach content inside an iframe or on another domain, so optional tracking
   could run when it should not.
 * **Privacy and PII testing.** Forms and tracking on a third-party page may send
   personal information to places your privacy review or security scans did not 
   account for, and the page may not pass those tests as it stands.
 * **Extra work to line things up.** Matching the page to your site’s tracking and
   cookie banner usually means additional configuration, such as cross-domain measurement,
   consent settings or changes inside the platform, and then retesting.

None of this makes third-party tools unusable, but it should be planned and tested
rather than assumed. Our articles on [how cookie categories control tags in Google Tag Manager](https://aztandc.com/articles/onetrust-google-tag-manager-cookie-categories)
and [how to test whether GTM and GA4 respect cookie consent](https://aztandc.com/articles/test-gtm-ga4-cookie-consent)
explain how to check this. Your legal or privacy team should decide which requirements
apply to your organization.

When the page is built into your own site, it can use the same tag manager, consent
banner and form handling as every other page, so there is one set of rules to maintain
and test.

## Your team can edit it without a developer or AI

This is the part that matters most after launch. Once the page is built into WordPress,
your editors can change the content the same way they update any other page. They
can:

 * Rewrite headlines, paragraphs and calls to action
 * Swap images and update links and buttons
 * Correct a statistic or product detail in a few minutes

No developer is needed, and nobody has to go back to an AI tool and regenerate the
page. The navigation, footer and forms are managed in one place for the whole site,
so they update everywhere at once. The design and animation stay in place while 
the content stays easy to change.

## Build it once, reuse it on other pages

A page built into WordPress is easy to copy. Once the design is in place, it can
be duplicated as the starting point for other pages, such as another product, campaign,
location or audience. Editors change the content, and the layout, styling and animation
come along. That saves time compared with recreating each page in a design tool 
and keeps every page consistent with the first.

## A recent example

The [data center chillers page on the G&D Chillers website](https://gdchillers.com/applications/data-center-chillers)
is a recent example. The main content was created with AI, along with the animation,
such as the moving dashes. The navigation, footer and forms use the same components
as the rest of the site, and the content remains editable in WordPress.

## What to get right

AI-designed pages still need careful finishing. Before launch, we check that:

 * The finished page matches the approved design on desktop and mobile
 * Animations respect visitors’ reduced-motion settings and the page is accessible
 * The page loads quickly and does not hurt Core Web Vitals
 * Forms, tracking and consent behave correctly, with no unexpected cookies or trackers
 * A person reviews the AI-written copy for accuracy and brand voice

Brand consistency is also easier to protect when the page shares the site’s own 
components. For more on that, read [Is Your Website Still On Brand?](https://aztandc.com/articles/is-your-website-still-on-brand-how-design-and-voice-drive-roi)

## When an embed still makes sense

Third-party tools are not wrong. For a short-lived campaign, a standalone microsite,
or an experience that depends on a specific tool’s interactive features, an embed
can be the right call. If you go that way, review the cookies and tracking the page
sets, confirm how it works with your consent banner, and test it before launch. 
If the page is meant to be a lasting part of your website, building it into the 
site usually serves you better.

## Planning a landing page?

If you are weighing an AI or hosted page builder for your next campaign, it is worth
deciding where the page will live before you start. AZTANDC can help you design,
build and measure it as part of your website. Learn more about our [custom development and integrations](https://aztandc.com/services/custom-development),
[analytics, SEO and privacy services](https://aztandc.com/services/analytics-seo-privacy)
and [AI and site automation](https://aztandc.com/services/ai-site-automation), or
[contact us](https://aztandc.com/contact) to talk through your project.

## Why Ongoing Digital Marketing Is Hard to Manage In-House

- Link: https://aztandc.com/articles/why-ongoing-digital-marketing-is-hard-to-manage-in-house
- Published: 2026-10-04T16:29:50-07:00
- Author: aztandc

A company can launch a strong website and still struggle to stay visible online.
Services change, customers ask new questions, search results shift, and social channels
need fresh material. Keeping up with that work takes more than an occasional post
or a website update when someone has time.

For many businesses, the challenge is consistency. The person handling marketing
often has other daily responsibilities. When customer needs or operations take priority,
website updates, articles, emails, and social posts are delayed. Over time, the 
website and marketing channels can stop reflecting what the business actually offers.

## The Work Continues After a Campaign Launches

Digital marketing is a cycle of planning, publishing, measuring, and improving. 
A practical routine may include updating service pages, writing useful articles,
preparing social posts, sending email campaigns, and reviewing which efforts bring
qualified visitors and inquiries.

Those tasks also need to connect. A social post should lead to a relevant page. 
An email should have a clear next step. Website content should answer the questions
customers are asking now. Reporting should help the team decide what to update next.

Handling all of this internally can work when a company has dedicated staff, a clear
process, and time to follow through. Without those resources, even good ideas can
become a backlog.

## Why Outside Marketing Support Can Help

A digital marketing firm gives the work an owner and a regular schedule. It can 
help set priorities, create content, coordinate campaigns, and review results while
the internal team contributes its knowledge of customer needs, service changes, 
and business goals.

For example, [Designer Marketing Solutions](https://designermarketingsolutions.com/)
offers social media management, search-friendly content writing, email marketing,
analytics reporting, graphic design, and web development. A business might use that
combination to keep its website content current, maintain a steady social presence,
send relevant customer emails, and use performance reports to guide the next round
of updates.

The value is not simply producing more posts. It is maintaining a coordinated effort
over time and adjusting it when the business or its audience changes.

## Your Team Still Has an Important Role

Hiring a firm does not mean handing over every decision. The business should define
its goals, approve its messaging, share timely updates, and identify the types of
inquiries that matter most. The marketing firm can turn that direction into a workable
plan and keep the day-to-day activity moving.

It also helps to agree on what success means. More traffic alone may not be the 
goal. Depending on the business, useful measures could include qualified inquiries,
calls, form submissions, email engagement, or interest in a particular service. 
Regular reviews make it easier to invest in what is working and change what is not.

## Keep the Website and Marketing Connected

Ongoing marketing depends on a website that can support it. Campaign pages need 
to work well on phones, forms need to deliver inquiries reliably, and analytics 
need to capture meaningful actions. When a service or offer changes, the website
should be updated along with the marketing that points to it.

[AZTANDC](https://aztandc.com/) helps businesses with the technical side of that
work, including website development, integrations, search optimization, analytics,
performance, and ongoing support. A marketing firm can focus on planning, content,
and campaigns while the underlying website and measurement systems support those
efforts.

If your team has good marketing intentions but limited time to carry them out consistently,
consider where outside help would have the most impact. [Designer Marketing Solutions](https://designermarketingsolutions.com/)
is one option for businesses looking for ongoing digital marketing support. The 
right arrangement gives your internal team a clear voice in the work and gives the
work itself the attention it needs.

## OneTrust + Google Tag Manager: How Cookie Categories Control Tags

- Link: https://aztandc.com/articles/onetrust-google-tag-manager-cookie-categories
- Published: 2026-10-03T00:00:00-07:00
- Author: aztandc

Installing a OneTrust banner doesn’t mean every script on your site respects the
visitor’s consent choices. The banner collects preferences. Your website, and your
Google Tag Manager (GTM) container, must then apply them to analytics, advertising,
embeds, and other optional technology.

This guide explains how OneTrust cookie categories control GTM tags. It covers the`
OnetrustActiveGroups` variable, category-based triggers, consent changes, Google
Consent Mode, and how to test the result.

## Why Use Google Tag Manager for Consent Management?

A website may use Google Analytics, advertising pixels, conversion tracking, customer-
support tools, and more. Each service needs a script or tracking tag. Without a 
central approach, those scripts end up scattered across theme files, plugins, and
header settings. That makes it hard to know what loads, when it loads, and which
consent category should control it.

GTM gives you one place to manage tags and their firing rules. Once the container
is installed, many tag changes can be made there without editing your templates.
Some implementations still need development work to supply the events and data those
tags rely on.

For consent, the main advantage is visibility. You can review the tags in the container,
identify their purpose, and check the conditions that allow each one to run.

GTM is optional. OneTrust can also work with scripts loaded directly by your website.
GTM is most useful when you want to manage several tracking services and their rules
together.

## How Do OneTrust and GTM Work Together?

The integration follows a sequence:

 1. OneTrust establishes the visitor’s current consent preferences.
 2. The integration makes those preferences available to GTM.
 3. GTM evaluates the relevant consent controls when a tag is triggered.
 4. The tag runs, is blocked, or adjusts its behavior according to its configuration.

For example, a visitor might allow analytics but reject advertising. Your implementation
should apply those choices separately. Accepting one optional category is not permission
for every tag.

The sections below cover a category-based trigger approach. Google tags that support
Consent Mode have their own consent features, which are covered separately below.

## What Is OnetrustActiveGroups?

`OnetrustActiveGroups` is a data layer value that OneTrust can provide. It lists
the currently active category IDs, based on the visitor’s preferences or your configured
defaults.

A data layer lets a website and its integrations pass information to GTM. A GTM 
Data Layer Variable reads a particular value from it. An example value looks like
this:

    ```
    ,C0001,C0002,C0003,
    ```

Category IDs are identifiers, not descriptive names. Before you write a firing rule,
confirm which ID matches the category that should control the tag. Verify the IDs
in your own OneTrust configuration, because not every implementation uses the same
mapping.

## How to Create the OnetrustActiveGroups Variable in GTM

To make active categories available in your trigger conditions:

 1. Open your GTM container and select **Variables**.
 2. Create a new user-defined variable.
 3. Select **Data Layer Variable** as the type.
 4. Set the **Data Layer Variable Name** to `OnetrustActiveGroups`, keeping the capitalization.
 5. Give the variable a recognizable name, such as `OnetrustActiveGroups`, and save
    it.

Use GTM **Preview** to confirm the variable receives the expected value when OneTrust
updates consent.

## How to Use a Cookie Category to Control a Tag

Suppose you’ve verified that `C0002` is the category required for a particular optional
tag. A condition can check for the complete category token:

    ```
    Variable: OnetrustActiveGroups
    Operator: matches RegEx
    Value: ,C0002,
    ```

These lines describe fields in the GTM interface. They aren’t JavaScript to paste
into your website.

The surrounding commas mark the boundaries of the category ID. That makes the condition
more precise than searching for an unbounded fragment of the value.

## What Happens When a Visitor Changes Consent?

OneTrust provides a data layer event named `OneTrustGroupsUpdated`. A GTM Custom
Event trigger can listen for it and evaluate the category condition. For a tag that
should start when the category becomes active, configure:

    ```
    Trigger type: Custom Event
    Event name: OneTrustGroupsUpdated
    Fire on: Some Custom Events
    Condition: OnetrustActiveGroups matches RegEx ,C0002,
    ```

This helps when a visitor grants consent without reloading the page. Keep these 
cautions in mind:

 * **Consent updates aren’t business events.** Don’t use this event in place of 
   a purchase, form submission, or other action you want to measure.
 * **Check repeated updates and consent withdrawal.** A trigger can’t undo JavaScript
   that has already loaded.

## Match the Trigger to the Tag’s Purpose

Before you apply a consent trigger, decide what the tag is meant to do:

 * **Load an optional service:** The service may need to initialize when its required
   consent becomes available.
 * **Record a form submission:** The tag should respond to a real submission and
   check the required consent at that moment.
 * **Record a purchase:** The tag should respond to the purchase event, with the
   correct transaction details and consent controls.

Attaching every tag to a consent-update event can produce incorrect measurements.
Accepting cookies should never be recorded as a purchase or a form submission.

## Why Multiple GTM Triggers Can Break Consent Controls

A common mistake is adding a consent trigger alongside an existing firing trigger
and assuming both conditions must be true. Separate firing triggers on a tag mean
_either_ one can fire it. An existing **All Pages** trigger can therefore undermine
your consent restriction.

A **Trigger Group** waits until all of its member triggers have fired at least once
on the page. That can combine event requirements, but it doesn’t continuously check
that consent is still granted.

For a tag that measures a specific action, design the setup so the required consent
is checked when the action happens. Depending on the tag, that may involve GTM’s
consent settings, conditions on the action trigger, or an exception evaluated on
the same event.

Test the full sequence you intend to support: consent granted, withdrawn, and granted
again. A Trigger Group alone doesn’t handle every consent change.

## How Does OneTrust Relate to Google Consent Mode?

OneTrust category IDs and Google’s consent types are different systems. Seeing `
C0002` in the active groups doesn’t prove that Google has received an `analytics_storage`
consent update. If you use Google Consent Mode, verify the integration that maps
your preferences to Google’s consent states.

Google tags that support Consent Mode have built-in consent checks. Other tags may
need additional consent requirements or category-based blocking. Expected behavior
also depends on your setup:

 * **Basic Consent Mode:** Google tags are blocked until the relevant consent is
   granted.
 * **Advanced Consent Mode:** Google tags load with denied defaults and can send
   cookieless pings before consent is granted.

So a network request before consent doesn’t automatically mean your implementation
is faulty. Compare what you observe with the consent model you intentionally configured.

Consent defaults must be set before measurement tags run, then updated once the 
visitor’s preferences are known. GTM offers a **Consent Initialization** trigger
for integrations that set those defaults.

## Don’t Forget Scripts Outside GTM

GTM is only part of a consent audit. A site may also load analytics, advertising,
embeds, or other third-party JavaScript directly through:

 * Theme templates
 * CMS plugins
 * Header/footer injection
 * Custom JavaScript
 * Embedded forms
 * Iframes

These scripts don’t become consent-aware just because GTM is configured correctly.
For example, a marketing platform might be loaded once by a WordPress plugin and
again through GTM. Controlling the GTM copy leaves the plugin’s copy unaffected,
and it can also cause duplicate tracking.

Review where each service is installed and make sure its consent controls cover 
every loading path.

## How to Test Your OneTrust and GTM Consent Setup

Test from a clean browser session. Use GTM Preview alongside the browser’s Network
and storage tools.

 1. **Before interacting with the banner:** Check the initial consent state and which
    services load.
 2. **Reject optional categories:** Confirm behavior matches your configured consent
    model.
 3. **Allow one category:** Check that the matching functionality becomes available
    without enabling unrelated services.
 4. **Perform a real action:** Test a form submission, purchase, or other event. Confirm
    the correct tag fires once with the expected information.
 5. **Withdraw consent:** Check the updated state, later events, and behavior after
    navigating to another page.
 6. **Return to the site:** Confirm saved preferences are applied before optional services
    run.

For each relevant event, inspect the consent state, variable values, tags that fired,
tags that were blocked, and actual network activity.

Pay particular attention to withdrawal. Blocking future tag executions doesn’t necessarily
stop an already loaded service or remove cookies it created earlier. Check what 
each service and your integration require to handle withdrawal.

Treat consent management as an implementation that needs testing, not a banner installed
on top of a website.

## Frequently Asked Questions

**Does OneTrust automatically block Google Tag Manager tags?**
No. The banner collects
preferences, but your implementation must apply them to the tags in your container
and to scripts loaded elsewhere.

**Do I need GTM to use OneTrust?**
No. OneTrust can also work with scripts loaded
directly by your website. GTM is useful when you want to manage multiple tracking
services and their rules in one place.

**What does `OnetrustActiveGroups` contain?**
It contains the currently active OneTrust
category IDs, such as `,C0001,C0002,C0003,`. Verify which ID maps to which category
in your own configuration.

**Does a network request before consent mean my setup is broken?**
Not necessarily.
With Advanced Consent Mode, Google tags can send cookieless pings before consent
is granted. Compare what you see with the consent model you configured.

## Get Help with Consent and Analytics Implementation

AZTANDC helps organizations implement and troubleshoot consent management, Google
Tag Manager, analytics, and the web technology around them. We can review how your
tags load, how consent choices reach them, and whether the resulting behavior matches
your intended configuration.

## References

 * [OneTrust: Google Tag Manager integration](https://developer.onetrust.com/onetrust/docs/google-tag-manager)
 * [Google: Trigger Groups](https://support.google.com/tagmanager/answer/9164222?hl=en)
 * [Google: Tag Manager consent support](https://support.google.com/tagmanager/answer/10718549?hl=en)
 * [Google: Consent Mode overview](https://developers.google.com/tag-platform/security/concepts/consent-mode)

## How to Test Whether GTM and GA4 Respect Cookie Consent

- Link: https://aztandc.com/articles/test-gtm-ga4-cookie-consent
- Published: 2026-10-02T00:00:00-07:00
- Author: aztandc

A consent banner appearing on a website doesn’t prove that Google Tag Manager, Google
Analytics 4 or other marketing technology respects the visitor’s choices.

The banner collects preferences. The implementation must apply those preferences
to the tags, scripts and services running on the website.

Here is a practical process for testing GTM and GA4 with your consent management
platform. The main checks apply regardless of which platform you use. OneTrust-specific
checks are included as optional steps.

## Define the Expected Behavior First

Before testing, identify which services should run before consent, which require
permission, and what should happen when permission is withdrawn.

If you use Google Consent Mode, distinguish between the two implementation models:

 * **Basic Consent Mode:** Google tags are blocked until the relevant consent is
   granted.
 * **Advanced Consent Mode:** Google tags can load with denied consent defaults 
   and send cookieless pings before consent is granted.

This distinction matters when inspecting network activity. A Google request before
consent does not automatically mean the implementation is incorrect. Its behavior
must match the model you have intentionally configured.

Also identify any regional differences. Your website may display different choices
or apply different defaults depending on the visitor’s location.

## Start With a Clean Session

Existing cookies and saved preferences can make consent testing misleading.

Start with a new private/incognito browser session or clear the site’s cookies and
storage before testing. Close existing private windows before starting a fresh session,
because private windows can share session data.

Open your browser’s developer tools before loading the page so you can capture the
initial network requests.

Then open the website without interacting with the consent banner.

Browser privacy settings and extensions can independently block tracking. Record
those conditions so you don’t mistake browser blocking for working website consent
controls.

## Check the Initial Consent State

In Chrome or Edge developer tools, inspect:

**Application → Cookies**

and:

**Network**

Other browsers provide similar tools, although their names and locations may differ.

Check what loads before the visitor makes a choice:

 * Cookies and other browser storage
 * GA4 requests
 * Advertising requests
 * Other third-party scripts and embeds

If Google Consent Mode is configured, use Tag Assistant to inspect the consent state.
Relevant consent types can include `analytics_storage`, `ad_storage`, `ad_user_data`
and `ad_personalization`.

Confirm that the intended defaults are established before measurement tags run. 
A consent update arriving later does not correct requests that have already occurred.

## Reject Optional Cookies

Choose the option that rejects optional categories, where your banner provides one.

Then check:

 * Cookies created in the browser
 * Network requests
 * GTM tags that fired
 * GA4 requests
 * Advertising requests
 * Other third-party scripts

Navigate to another page and repeat the checks. The rejection should remain effective
as the visitor continues through the website.

Don’t test only for cookies. A third-party request can occur without leaving behind
the cookie you expected to find.

Compare the observed requests and storage behavior with your configured consent 
model.

## Accept Categories Separately

If your preference center supports separate categories, enable one optional category
at a time.

For example, allow analytics while leaving advertising denied. Confirm that analytics
behaves as expected without enabling unrelated advertising tags.

Then test the actions your website measures, such as a form submission or purchase.
Confirm that the appropriate event is recorded once, with the expected information.

Changing a consent preference should not accidentally generate a duplicate page 
view or be recorded as a business conversion.

## Inspect Your Consent Platform’s Signals

Your consent platform may communicate preferences through data layer values, browser
events, cookies or a GTM template.

Check the integration your website actually uses. The platform’s recorded preferences
should agree with the consent state and tag behavior visible in GTM.

Do not assume that installing a banner automatically connects its choices to every
tag.

## If You Use OneTrust: Inspect Active Categories

For OneTrust implementations using its active-group integration, inspect the GTM
Data Layer Variable named:

    ```language-text
    OnetrustActiveGroups
    ```

In GTM Preview, select the relevant consent event and inspect the variable’s value.
It may contain a comma-delimited list such as:

    ```language-text
    ,C0001,C0002,
    ```

Confirm that the active category IDs correspond with the choices you made in the
banner.

Verify the category mapping in your own OneTrust configuration. Do not assume that`
C0002` represents analytics on every website.

If Google Consent Mode is also used, check its consent states separately. An active
OneTrust category does not by itself prove that the corresponding Google consent
update was sent.

## Test the Consent Change Event

Change your preferences without reloading the page. Verify that your consent platform
communicates the change and that the relevant tags respond correctly.

If you use OneTrust’s event-based integration, look for:

    ```language-text
    OneTrustGroupsUpdated
    ```

If GTM tags rely on this event, confirm that it appears in Preview and that the 
active-category values are correct when the trigger is evaluated.

For example, if you have verified that analytics requires `C0002`, accepting that
category should make it active and allow the configured analytics logic to proceed.

For other consent platforms, inspect their documented update event or consent integration
instead.

## Test Regional Consent Behavior

If the website uses regional consent rules, repeat the tests for the regions your
implementation supports.

Check the banner, initial consent state, available choices and resulting tag behavior
for each region.

### If You Use OneTrust: Test With otgeo

OneTrust supports a geographic testing override through the `otgeo` URL parameter.
Supply a two-letter ISO country code, such as `US`, `GB`, `DE` or `FR`:

    ```language-text
    https://example.com/?otgeo=DE
    ```

Replace `example.com` with your website address. This example tests the OneTrust
rule selected for Germany.

If the URL already contains a query parameter, append `&otgeo=DE` instead:

    ```language-text
    https://example.com/?test=1&otgeo=DE
    ```

For US state rules, use a country and state code separated by a comma. For example,
to test New Jersey:

    ```language-text
    https://example.com/?otgeo=us,nj
    ```

Start each regional test with cleared consent storage. Confirm that the intended
rule loaded rather than judging only by the banner’s appearance.

With OneTrust loaded, run the following in the browser’s developer console to inspect
its diagnostic information:

    ```javascript
    OneTrust.testLog();
    ```

Review the geolocation, rule and template information. Then repeat the rejection,
acceptance and withdrawal tests for that region.

The override changes the location used by OneTrust for testing. It does not change
your actual network location or automatically test other location-dependent website
features.

If you use another consent platform, use its supported regional preview or geographic
testing method.

## Use GTM Preview During Testing

Google Tag Manager’s Preview mode connects your test session to Tag Assistant, helping
you determine:

 * Which events occurred
 * Which tags fired
 * Which tags didn’t fire
 * Which trigger conditions succeeded or failed
 * Which variable values were available
 * Which consent states were recorded

Inspect the initial page events, consent updates and actual business events separately.

A tag firing in Preview does not necessarily mean the receiving service recorded
the expected event. Check the corresponding network activity and, where appropriate,
GA4 DebugView.

Repeat the main checks outside Preview after publishing. The live website should
exhibit the expected behavior too.

## Check Scripts Outside GTM

Consent testing must cover the whole website, including services loaded outside 
your GTM container.

Check for scripts installed through:

 * Theme templates
 * CMS plugins
 * Header/footer settings
 * Embedded forms
 * Videos and iframes
 * Custom JavaScript

A service loaded directly by a plugin does not automatically inherit the consent
restrictions applied to a GTM tag.

Also check for duplicate installations. The same analytics service running through
both GTM and a plugin can produce duplicate events and inconsistent consent behavior.

## Test Consent Withdrawal Too

Testing shouldn’t stop at Accept.

Try this sequence:

 1. Start with optional consent denied.
 2. Enable an optional category.
 3. Confirm the expected behavior.
 4. Reopen cookie settings.
 5. Withdraw that consent.
 6. Inspect consent updates and subsequent requests on the current page.
 7. Navigate to another page.
 8. Confirm that the withdrawn preference remains effective.

Consent withdrawal is easy to overlook when QA focuses only on the initial banner.

Blocking future GTM tag executions does not automatically unload scripts that are
already running or remove previously created cookies. Verify how each service and
its integration handles withdrawal.

## Repeat After Major Website Changes

Consent implementations can break when teams add:

 * New GTM tags
 * Plugins
 * Marketing platforms
 * Embedded forms
 * Videos
 * Iframes
 * Analytics products
 * Advertising scripts

Repeat testing after changes to consent categories, regional rules or Consent Mode
settings as well.

Record the region, consent choices, expected behavior and observed results. This
makes later comparisons easier and helps identify which change introduced a problem.

Consent testing should be part of ongoing website governance rather than a one-time
launch task.

### Need Help Testing Your Implementation?

AZTANDC works with Google Tag Manager, GA4, consent management platforms and web
implementations to help identify scripts that are firing unexpectedly and determine
where consent controls need to be applied. For websites using OneTrust, we can also
review category mappings, consent updates and regional behavior.

## References

 * [Google: Tag Manager consent support](https://support.google.com/tagmanager/answer/10718549?hl=en)
 * [Google: Consent Mode overview](https://developers.google.com/tag-platform/security/concepts/consent-mode)
 * [OneTrust: Google Tag Manager integration](https://developer.onetrust.com/onetrust/docs/google-tag-manager)
 * [Softcrylic: OneTrust geographic testing and diagnostic tips](https://www.softcrylic.com/blogs/debugging-onetrust-lesser-known-tips-tricks/)

## How Much Does a Custom WordPress Plugin Cost?

- Link: https://aztandc.com/articles/custom-wordpress-plugin-development-cost
- Published: 2026-10-01T00:00:00-07:00
- Author: aztandc

A custom WordPress plugin is built around your specific business requirements. You
might need a workflow unique to your organization, a connection to an internal system,
or functionality that existing plugins cannot provide.

So, how much does a custom WordPress plugin cost? The estimate depends on what must
be designed, developed, tested and supported to deliver that functionality.

A focused plugin that adds your organization’s required fields to an RSS feed involves
a different amount of work than a custom application that synchronizes data with
an external system, controls access for different users and provides reporting tools.

Custom plugin development includes more than writing code. It involves understanding
your requirements, deciding how the functionality should work within WordPress, 
handling errors and testing it in your website’s environment.

**To understand the cost, start with what your custom plugin needs to do—and what
it needs to handle when something goes wrong.**

## What Makes a WordPress Plugin Custom?

A custom plugin is developed to meet requirements specific to your website or organization.
Those requirements might include:

 * A business workflow with your own rules and approval steps
 * An integration with an internal application or external service
 * Custom data collection, validation and reporting
 * Different functionality for specific user roles
 * Changes to how your website publishes or distributes content
 * Automation that replaces a manual process

The cost depends on the scope of those requirements. A plugin with one clearly defined
task can remain compact. A plugin supporting several connected workflows requires
more planning, development and testing.

## Focused Custom Plugins

A relatively small custom plugin might:

 * Add a shortcode that displays information in a specific format
 * Modify existing CMS behavior to match your publishing process
 * Add custom fields with business-specific validation
 * Change an email based on your organization’s rules
 * Extend a feed with fields required by another system
 * Add a small admin setting
 * Automate a repetitive task

These projects can often be kept compact because they use functionality already 
provided by WordPress.

Clearly defined requirements also make the work easier to estimate. For example,
specifying the exact fields, output format and conditions for a feed modification
gives a developer a much clearer scope than asking for a plugin to “improve our 
feeds.”

## Custom Integrations Add Complexity

Development time increases when the plugin communicates with another system.

Examples include:

 * CRM platforms
 * Internal business applications
 * External APIs
 * Cloud services
 * Email platforms
 * Analytics systems

The code that sends or receives data is only part of the work.

The integration may also require authentication, field mapping, validation, API 
limits, logging and a strategy for what happens when the external service is unavailable.

A one-way transfer is also different from ongoing synchronization. If both systems
can change the same information, the plugin needs rules for identifying the current
value, resolving conflicts and preventing duplicate records.

Those decisions affect the estimate because they determine how much custom behavior
must be implemented and tested.

## Administrative Interfaces Take Time

A plugin may work perfectly without a sophisticated dashboard.

But if nontechnical users need to configure or operate it, development may also 
involve:

 * Settings screens
 * Validation
 * Permissions
 * Status information
 * Error messages
 * Reporting
 * Import/export tools

Good administration tools can require as much thought as the front-end functionality.

For example, an automated import may also need a screen showing when it last ran,
which records failed and whether an administrator can safely retry them. Each of
those features adds work beyond the import itself.

## User Data and Permissions Matter

Complexity also increases when a plugin introduces different types of users or private
information.

A plugin may need to determine:

 * Who can see information
 * Who can modify it
 * Which administrators have access
 * What should happen when a user is deleted
 * What information should remain in the database

These decisions should be made before development rather than added after the plugin
is already built.

The estimate should include implementing and testing these access rules. Hiding 
a button is not enough; the plugin must enforce permissions when someone requests
or changes the underlying information.

## Testing Is Part of Custom Development

A custom plugin needs to be tested against the requirements it was built to meet.

That includes the expected workflow and situations such as:

 * Missing or invalid input
 * Users without the required permissions
 * Unavailable external services
 * Repeated submissions or duplicate records
 * Large imports or longer-running tasks
 * Interactions with the site’s theme and other plugins

The more conditions the plugin must support, the more testing the project requires.
Defining what counts as a successful result helps make that work part of the estimate
from the beginning.

## Custom Plugins Should Be Well Documented

A custom plugin doesn’t exist in isolation.

It operates alongside:

 * WordPress
 * PHP
 * The active theme
 * Other plugins
 * External APIs
 * Hosting infrastructure

Those systems change.

A custom plugin should therefore be written so another developer can understand 
it, troubleshoot it and update it later.

When reviewing an estimate, ask what is included in the initial delivery and what
is covered separately. Documentation, deployment, support, compatibility updates
and future enhancements should have clear expectations.

## What to Provide for a Custom Plugin Estimate

You don’t need a complete technical specification to start a conversation. A clear
explanation of the business requirement is more useful than a long list of implementation
details.

Helpful information includes:

 * The problem the plugin should solve
 * Who will use it and what they need to do
 * The required inputs and outputs
 * Any systems it must connect to
 * Examples of the workflow or expected result
 * The approximate volume of users, records or requests
 * Which features are required for launch and which can follow later

This helps distinguish a focused custom plugin from a larger development project
and reduces uncertainty in the estimate.

## Start With the Requirement, Not the Plugin

Sometimes a client asks for a plugin when the requirement can be met through a theme
change, an existing product or a small extension to functionality already in place.

The first step should be defining the business requirement.

Then determine the simplest reliable way to implement it. Custom development can
use established WordPress functionality for standard tasks while adding the behavior
specific to your organization.

A useful estimate should explain what will be delivered, the assumptions behind 
the scope and which requirements could change the cost.

### Custom WordPress Development

AZTANDC develops custom WordPress functionality, plugins, integrations and web applications.
We can review your workflow or project specification, identify the functionality
that needs custom development, and help define a practical scope before you commit
to building it.

## Useful Azure Front Door WAF KQL Queries for Troubleshooting

- Link: https://aztandc.com/articles/azure-front-door-waf-kql-queries
- Published: 2026-09-30T00:00:00-07:00
- Author: aztandc

When Azure Front Door diagnostic logs are stored in Log Analytics, Kusto Query Language(
KQL) can quickly answer questions about WAF activity.

Here are several queries we commonly find useful when troubleshooting Front Door.

These examples use the `AzureDiagnostics` table. They retrieve user agents from 
Front Door access logs and correlate them with WAF events using `trackingReference_s`.

Run each query separately. Copy only the code inside the query block, excluding 
article headings and explanatory text. For queries beginning with `let`, run the
entire block together, including the ending semicolon on the variable definition.

Set the Log Analytics time range to include the requests you’re investigating. Both
access logs and WAF logs must be enabled and sent to the workspace for the queries
that combine them. If your workspace contains multiple Front Door profiles, narrow
your investigation to the relevant resource.

## Show Recent WAF Blocks

    ```language-kusto
    AzureDiagnostics
    | where Category =~ "FrontDoorWebApplicationFirewallLog"
    | where action_s =~ "Block"
    | project
        TimeGenerated,
        ClientIP = clientIP_s,
        RequestURL = requestUri_s,
        Rule = ruleName_s,
        Action = action_s,
        TrackingReference = trackingReference_s
    | order by TimeGenerated desc
    ```

This is usually the best starting point.

The user agent is retrieved from the access log in the queries below rather than
directly from the WAF log.

## Count Blocks by WAF Rule

    ```language-kusto
    AzureDiagnostics
    | where Category =~ "FrontDoorWebApplicationFirewallLog"
    | where action_s =~ "Block"
    | summarize BlockCount = count() by Rule = ruleName_s
    | order by BlockCount desc
    ```

This makes frequently triggered rules easy to identify.

`BlockCount` counts blocking WAF log entries. It is not a guaranteed count of unique
requests, because multiple log entries can relate to the same request.

## Count Blocks by User Agent

    ```language-kusto
    let BlockedRequests =
        AzureDiagnostics
        | where Category =~ "FrontDoorWebApplicationFirewallLog"
        | where action_s =~ "Block"
        | where isnotempty(trackingReference_s)
        | distinct _ResourceId, trackingReference_s;
    AzureDiagnostics
    | where Category =~ "FrontDoorAccessLog"
    | where isnotempty(trackingReference_s)
    | summarize arg_max(TimeGenerated, userAgent_s)
        by _ResourceId, trackingReference_s
    | join kind=inner (BlockedRequests)
        on _ResourceId, trackingReference_s
    | summarize BlockCount = count() by UserAgent = userAgent_s
    | order by BlockCount desc
    ```

This is particularly useful when investigating bots, crawlers and automated services.

The query first identifies distinct blocked tracking references for each resource.
It then keeps the latest access-log entry for each resource and tracking reference
before joining the results. This prevents repeated WAF or access-log entries from
multiplying the count.

Here, `BlockCount` counts matched resource-and-tracking-reference pairs. Blocked
requests without a matching access-log entry in the selected time range are excluded.
An empty user-agent value means the matched access record did not provide one.

A user-agent string is supplied by the client and can be spoofed. Use it as supporting
information rather than proof of identity.

## Count Blocks by Client IP

    ```language-kusto
    AzureDiagnostics
    | where Category =~ "FrontDoorWebApplicationFirewallLog"
    | where action_s =~ "Block"
    | summarize BlockCount = count() by ClientIP = clientIP_s
    | order by BlockCount desc
    ```

An IP producing hundreds or thousands of blocking log entries can become obvious
immediately.

As with the rule-count query, `BlockCount` counts blocking WAF log rows rather than
guaranteed unique requests.

Keep in mind that IP addresses alone aren’t always reliable indicators of identity.
Proxies, shared infrastructure and other network configurations can cause multiple
users to appear behind the same address.

## Find WAF Activity for a Specific URL

    ```language-kusto
    AzureDiagnostics
    | where Category =~ "FrontDoorWebApplicationFirewallLog"
    | where requestUri_s contains "/your-path/"
    | project
        TimeGenerated,
        Action = action_s,
        ClientIP = clientIP_s,
        Rule = ruleName_s,
        RequestURL = requestUri_s,
        TrackingReference = trackingReference_s
    | order by TimeGenerated desc
    ```

Replace `/your-path/` with the portion of the URL you’re investigating.

This is useful for APIs, forms, RSS feeds and application endpoints.

This query includes all recorded WAF actions for matching URLs. To limit it to blocks,
add `| where action_s =~ "Block"` before the `project` statement.

## Search by User Agent

    ```language-kusto
    let MatchingRequests =
        AzureDiagnostics
        | where Category =~ "FrontDoorAccessLog"
        | where isnotempty(trackingReference_s)
        | summarize arg_max(TimeGenerated, userAgent_s)
            by _ResourceId, trackingReference_s
        | where userAgent_s contains "bot"
        | project
            _ResourceId,
            trackingReference_s,
            UserAgent = userAgent_s;
    AzureDiagnostics
    | where Category =~ "FrontDoorWebApplicationFirewallLog"
    | where isnotempty(trackingReference_s)
    | join kind=inner (MatchingRequests)
        on _ResourceId, trackingReference_s
    | project
        TimeGenerated,
        Action = action_s,
        ClientIP = clientIP_s,
        RequestURL = requestUri_s,
        Rule = ruleName_s,
        UserAgent,
        TrackingReference = trackingReference_s
    | order by TimeGenerated desc
    ```

Replace `bot` with the user-agent text you’re investigating.

The query searches the user agent in the latest access-log entry for each resource
and tracking reference, then retrieves matching WAF events.

It shows WAF activity associated with matching user agents, including actions other
than blocking. To show only blocks, add `| where action_s =~ "Block"` immediately
after the WAF category filter.

Requests without a matching WAF event do not appear. Multiple WAF events for the
same request can appear as separate rows because each row provides information about
a recorded WAF event.

## Look Up One Tracking Reference

Copy a `TrackingReference` value from one of the query results above. Replace `PASTE-
TRACKING-REFERENCE-HERE` with that exact value, keeping the quotation marks:

    ```language-kusto
    let Ref = "PASTE-TRACKING-REFERENCE-HERE";
    AzureDiagnostics
    | where Category in~ (
        "FrontDoorAccessLog",
        "FrontDoorWebApplicationFirewallLog"
    )
    | where trackingReference_s == Ref
    | order by TimeGenerated asc
    ```

The first line stores the tracking reference in a variable named `Ref`. The query
then uses `trackingReference_s == Ref` to find log entries with that exact value.

For example, if the value you copied were `example-reference-123`, the first line
would be:

    ```language-kusto
    let Ref = "example-reference-123";
    ```

That value is only an illustration. Use the actual tracking reference from your 
logs.

Run the entire lookup query together, including the `let Ref` line and its ending
semicolon. Set the Log Analytics time range to include when the request occurred.

The tracking reference is one of the most useful Front Door troubleshooting fields
because it can connect access-log and WAF activity belonging to the same request.

If only one log category appears, check that both categories are enabled and sent
to the workspace, that the selected time range includes the request, and that the
relevant logs have arrived.

## Don’t Assume Every Error Is WAF

This is an important part of interpreting these queries.

A failed request in the Front Door access log does not necessarily indicate a firewall
problem.

The WAF log records requests that match WAF rules. Access logs provide information
about requests processed through Front Door.

Looking at both—and correlating requests using their tracking reference—helps separate
WAF problems from origin and application problems.

For example, an HTTP 403 response alone does not prove that the WAF blocked the 
request. Look for a corresponding WAF event with a blocking action.

### Azure Troubleshooting Beyond the Query

KQL tells you what Azure recorded. The next step is interpreting it correctly.

AZTANDC works across the application, Azure Front Door, WAF, APIs and origin infrastructure
to help determine not only what failed, but where it failed.

## Azure Front Door WAF: How to Find Why a Request Was Blocked

- Link: https://aztandc.com/articles/azure-front-door-waf-find-blocked-requests
- Published: 2026-09-29T00:00:00-07:00
- Author: aztandc

Azure Front Door’s Web Application Firewall can block malicious traffic before it
reaches your application. But when legitimate traffic receives a 403 or an integration
suddenly stops working, the important question is:

**Did the WAF block it, and if so, which rule caused the block?**

Azure Log Analytics can usually answer that quickly.

## Start With Actual WAF Blocks

If Azure Front Door diagnostic logs are being sent to a Log Analytics workspace 
using `AzureDiagnostics`, start with:

    ```language-kusto
    AzureDiagnostics
    | where Category =~ "FrontDoorWebApplicationFirewallLog"
    | where action_s =~ "Block"
    | project
        TimeGenerated,
        ClientIP = clientIP_s,
        RequestURL = requestUri_s,
        Rule = ruleName_s,
        Action = action_s,
        TrackingReference = trackingReference_s
    | order by TimeGenerated desc
    ```

Using `=~` makes the comparison case-insensitive. This avoids missing matching records
because of capitalization differences.

Run only the code inside each query block. Do not paste article headings or explanatory
text into Log Analytics. Set the time range to include when the request occurred.
If your workspace contains logs from multiple Front Door profiles, narrow the query
to the relevant resource.

The results give you the basic information needed to investigate:

 * When the request occurred
 * Which URL was requested
 * Which WAF rule recorded the block
 * The client IP
 * Azure’s tracking reference

The user agent is available in the Front Door access log for the setup used here.
Use the tracking reference to look up the matching access-log entry, as shown below.

## Find Blocks for One URL

When troubleshooting a specific API endpoint, feed, form or page, narrow the results:

    ```language-kusto
    AzureDiagnostics
    | where Category =~ "FrontDoorWebApplicationFirewallLog"
    | where action_s =~ "Block"
    | where requestUri_s contains "/api/"
    | project
        TimeGenerated,
        ClientIP = clientIP_s,
        RequestURL = requestUri_s,
        Rule = ruleName_s,
        Action = action_s,
        TrackingReference = trackingReference_s
    | order by TimeGenerated desc
    ```

Replace `/api/` with the portion of the URL you need to investigate.

This is especially useful when an application uses several APIs and you don’t want
unrelated WAF activity obscuring the results.

## Count Blocks by Rule

If you want to determine which WAF rules are responsible for most blocking log entries:

    ```language-kusto
    AzureDiagnostics
    | where Category =~ "FrontDoorWebApplicationFirewallLog"
    | where action_s =~ "Block"
    | summarize BlockCount = count() by Rule = ruleName_s
    | order by BlockCount desc
    ```

This query counts WAF log rows with a blocking action, grouped by rule. Treat `BlockCount`
as a count of blocking log entries rather than a guaranteed count of unique requests.

This is useful when tuning a WAF policy because one problematic managed or custom
rule can become immediately obvious.

A high number of blocks does not automatically mean the rule should be disabled.
First determine what traffic is triggering it.

## Correlate the Request With the Access Log

One of the most useful Azure Front Door fields is `trackingReference_s`.

Azure assigns a tracking reference to a request, allowing activity for that request
to be correlated between Front Door logs. The tracking reference is also exposed
through the `X-Azure-Ref` response header.

Copy the `TrackingReference` value from the WAF query results above. Replace `PASTE-
TRACKING-REFERENCE-HERE` with that exact value, keeping the quotation marks:

    ```language-kusto
    let Ref = "PASTE-TRACKING-REFERENCE-HERE";
    AzureDiagnostics
    | where Category in~ (
        "FrontDoorAccessLog",
        "FrontDoorWebApplicationFirewallLog"
    )
    | where trackingReference_s == Ref
    | order by TimeGenerated asc
    ```

The first line stores the value in a variable named `Ref`. The query then uses `
trackingReference_s == Ref` to find log entries with the same tracking reference.

For example, if the value you copied were `example-reference-123`, the first line
would be:

    ```language-kusto
    let Ref = "example-reference-123";
    ```

That value is only an illustration. Use the actual tracking reference from your 
logs.

Run the entire query together, including the `let Ref` line and its ending semicolon.
Set the Log Analytics time range to include when the request occurred.

Both access logs and WAF logs must be enabled and sent to the workspace to retrieve
both types of records. If only one type appears, check the diagnostic settings, 
selected time range and whether the relevant logs have arrived.

This can help establish whether a suspicious HTTP response corresponds to an actual
WAF event rather than an application, origin or connectivity problem.

## Find the User Agent for the Request

To retrieve the user agent, use the same tracking reference to search the Front 
Door access log:

    ```language-kusto
    let Ref = "PASTE-TRACKING-REFERENCE-HERE";
    AzureDiagnostics
    | where Category =~ "FrontDoorAccessLog"
    | where trackingReference_s == Ref
    | project
        TimeGenerated,
        UserAgent = userAgent_s,
        TrackingReference = trackingReference_s
    | order by TimeGenerated asc
    ```

Replace the placeholder with the same value used in the correlation query. Run this
query separately, including its own `let Ref` line.

This lets you inspect the user agent associated with the access-log entry instead
of expecting it to be populated in the WAF log. A user-agent string is supplied 
by the client and can be spoofed, so use it as supporting information rather than
proof of identity.

## A 403 Doesn’t Automatically Mean WAF

This distinction matters.

Seeing an HTTP 403 in the Front Door access log does not by itself prove that the
WAF generated it. Applications and origins can also return 403 responses.

Check the WAF log for a corresponding blocking event.

That is one reason the tracking reference is so useful: it provides a much stronger
connection between the access request and WAF activity than relying on HTTP status
alone.

## Before Changing the WAF Rule

Once you’ve identified a blocking rule, determine:

 1. What URL triggered it?
 2. What client or application generated the request?
 3. Is the traffic legitimate?
 4. Is the rule managed or custom?
 5. Can the exception be limited to the affected request instead of disabling protection
    more broadly?

The objective shouldn’t be to eliminate WAF blocks.

The objective is to allow legitimate application traffic while continuing to block
unwanted traffic.

### Need Help With Azure Front Door?

AZTANDC works with Azure Front Door, WAF configuration, application troubleshooting,
security and web infrastructure. When an application problem crosses the boundary
between the website, CDN, firewall and origin, we can help isolate where the failure
is actually occurring.

## How AI Website Automation Helps Small Businesses Compete Online

- Link: https://aztandc.com/articles/how-ai-website-automation-helps-small-businesses-compete-online
- Published: 2026-08-30T13:43:33-07:00
- Author: aztandc

AI + Website Automation

A small-business website can do more than display information. With the right AI
and automation, it can answer questions, guide visitors, qualify inquiries, connect
online systems, and help customers take the right next step.

For many small businesses, a website is still treated like a digital brochure. It
explains what the company does, lists services, and provides a contact form. That
is useful, but modern websites can do much more. With the right AI and automation,
a website can answer common questions, guide visitors, qualify inquiries, connect
information across platforms, and help a business respond faster without making 
the experience feel impersonal.

AI website automation is not about replacing employees or handing every customer
interaction to a machine. It is about removing friction from the online journey.
The best implementations help visitors find accurate information, take the right
next step, and reach a person when human judgment is needed.

For small-business owners, that can mean a website that works harder around the 
clock while remaining secure, measurable, and aligned with the company’s voice.

## What Is AI Website Automation?

AI website automation combines artificial intelligence with rules, forms, integrations,
and analytics to make online experiences more responsive. AI can interpret a visitor’s
question or recognize patterns in submitted information. Automation then uses that
information to complete a defined action, such as displaying a relevant answer, 
routing a lead, creating a CRM record, or triggering a follow-up.

The distinction matters. AI provides interpretation and flexibility; automation 
provides predictable execution. A reliable website solution uses both carefully.
AI should not be given unlimited control, and every automated action should have
clear rules, safeguards, and a way to involve a person when necessary.

**The practical goal:** use AI to understand what a visitor needs, then use controlled
automation to deliver the appropriate online response or next step.

## Where AI and Automation Add Value to a Small-Business Website

Customer Experience

### Smarter Website Chat and Customer Guidance

An AI-powered website assistant can help visitors navigate services, locate policies,
understand terminology, or find the correct contact path. Unlike a basic chatbot
that follows a rigid decision tree, a well-designed assistant can interpret natural
questions and retrieve answers from approved website content or a controlled knowledge
source.

The goal is not to make the bot sound human. The goal is to provide useful, accurate
guidance. A strong implementation clearly identifies the assistant, limits answers
to reliable sources, and offers an easy path to contact a person when the available
information is not enough.

Lead Capture

### Better Contact Forms and Lead Qualification

Standard contact forms often send every submission to the same inbox. Website automation
can evaluate the visitor’s selections, location, requested service, timeline, or
other submitted details and send the inquiry to the right destination.

AI can help interpret free-form messages, identify the likely subject, flag missing
information, or suggest the appropriate category. The automation layer can then 
create a structured record, notify the correct team member, and deliver a relevant
confirmation to the visitor.

Visitor Journeys

### Personalized Online Paths

Not every visitor needs the same information. A potential customer may need a service
comparison, while an existing customer may be looking for documentation or support.
Website automation can use explicit choices and known context to guide each visitor
toward the most relevant content or action.

Practical personalization can be based on actions the visitor chooses to take, such
as selecting an industry, answering a few questions, choosing a service type, or
requesting a specific resource.

Connected Platforms

### Website-to-CRM and Marketing Integrations

A website becomes much more valuable when it connects with the systems that manage
customer relationships. Forms, calculators, downloads, appointment requests, and
ecommerce activity can send structured information to a CRM or marketing platform.

Fields must map correctly, duplicate records must be controlled, consent choices
must be honored, and failures must be logged. A polished front end is not enough
if the information disappears or arrives in the wrong place.

Content Discovery

### More Useful Website Search

Traditional website search often depends on exact words. Visitors may use different
terminology than the website does, causing relevant pages to remain hidden. AI-assisted
search can interpret intent and surface content that is meaningfully related to 
the question.

The system should still point visitors to the original content rather than inventing
unsupported answers. Clear links, citations, and boundaries make the information
easier to trust and verify.

Measurement

### Analytics That Measure Results

Website automation should be measurable. Businesses need to know whether visitors
are getting answers, completing forms, reaching important pages, or abandoning the
process.

Useful measurements may include completed conversations, unanswered questions, qualified
form submissions, referral paths, calculator completions, downloads, and assisted
conversions. These signals help improve the website based on actual behavior instead
of assumptions.

## AI Should Support the Website—not Control It

Small businesses do not need AI added to every page. Forcing AI into a process that
already works can make a website harder to maintain and less predictable. The right
starting point is a specific online problem with a measurable outcome.

Good candidates for AI website automation usually share several traits:

 * Visitors repeatedly ask the same questions but use different wording.
 * Form submissions must be reviewed and routed manually.
 * Website information is difficult to locate with standard navigation or search.
 * Online activity needs to flow into a CRM, reporting platform, or another connected
   system.
 * The business can define what a successful result looks like and measure it.

If the process is unclear, the data is unreliable, or no one owns the outcome, adding
AI will not solve the underlying problem. The workflow should be designed first;
the technology should support that design.

## What Small Businesses Should Protect

Any feature that collects questions, contact information, or behavioral data needs
appropriate safeguards. Before launching an AI-powered website feature, a business
should understand what information is being sent, where it is processed, how long
it is retained, and which third parties can access it.

A responsible implementation should include:

 * Approved data sources and clear limits on what the AI may answer.
 * Server-side validation and security controls for forms and integrations.
 * Privacy and consent handling that matches the website’s actual data use.
 * Logging and monitoring for failed requests, inaccurate responses, and broken 
   integrations.
 * A human escalation path for questions that require judgment or sensitive information.
 * Ongoing review as website content, services, and connected platforms change.

These controls are not optional extras. They are part of making automation reliable
enough to support real customers.

## A Practical Way to Start

The strongest first project is usually focused and easy to evaluate. Instead of 
trying to create an all-purpose AI website, choose one online interaction that causes
friction and improve it in stages.

 1. Identify one repeated website problem, such as unanswered service questions, poorly
    routed inquiries, or difficult content discovery.
 2. Define the approved information, rules, systems, and people involved in the process.
 3. Build a limited version with clear boundaries and a fallback when the system cannot
    complete the task.
 4. Track the interactions and establish a baseline for completion, response quality,
    and conversion.
 5. Review the results, refine the experience, and expand only when the first workflow
    is stable.

This approach controls risk and produces useful evidence. It also makes it easier
to distinguish a meaningful improvement from an AI feature that merely looks impressive
in a demonstration.

## How AZTANDC Builds Smarter Online Experiences

AI website automation rarely succeeds as a standalone widget. It may need to work
with a content management system, custom forms, ecommerce, APIs, cloud services,
analytics, privacy controls, and security infrastructure. Those connections determine
whether the experience is dependable after launch.

AZTANDC LLC builds and integrates web and cloud solutions across the full online
stack. That includes custom website development, form and CRM integrations, Microsoft
Azure and Cloudflare architecture, analytics and Google Tag Manager tracking, performance
tuning, security hardening, and search optimization. This engineering-led approach
makes it possible to design AI features around the website’s real content, business
rules, and measurement goals.

The result should not be AI for its own sake. It should be a faster, clearer, and
more useful online experience that helps customers move forward and gives the business
better information about what is working.

Build a Smarter Online Experience

## Turn Your Website Into a More Useful Business Tool

If visitors struggle to find answers, inquiries require too much manual sorting,
or your website does not connect cleanly with the platforms behind it, AZTANDC can
design a secure, measurable solution around your actual online workflow.

[Discuss Your Website Automation Project](https://aztandc.com/contact/)

Custom website automation, integrations, analytics, security, and cloud solutions.

## Securely Share WordPress Draft Pages Without Creating User Accounts

- Link: https://aztandc.com/articles/securely-share-wordpress-draft-pages-without-creating-user-accounts
- Published: 2026-07-05T20:14:06-07:00
- Author: aztandc

One of the most common challenges with managing a WordPress website is getting feedback
on content **before it is published**.

Whether you’re reviewing a new web page, blog post, landing page, or custom content,
you often need input from marketing teams, executives, legal departments, clients,
or other stakeholders. Unfortunately, WordPress doesn’t make this easy.

The typical options all have drawbacks:

 * Publish the page before it’s approved.
 * Create temporary WordPress accounts for reviewers.
 * Walk reviewers through the login process.
 * Share screenshots or PDFs that don’t accurately represent the live page.

None of these are ideal.

### A Better Way to Review Unpublished Content

To solve this problem, AZTANDC developed the **Client Preview Links** plugin for
WordPress.

The plugin allows editors to generate a **secure preview link** for unpublished 
content and share it with anyone who needs to review it.

Reviewers simply click the link and view the page in their browser — **no WordPress
account, login, or technical knowledge required**.

The content remains unpublished and under your control until you’re ready to make
it live.

### Supported Content

The plugin can generate secure preview links for:

 * Draft pages and posts
 * Pending Review content
 * Scheduled future content
 * Private pages and posts
 * Custom Post Types

### How It Works

Using the plugin takes only a few seconds.

 1. Create or edit your content as usual.
 2. Generate a secure preview link.
 3. Optionally set an expiration date for the link.
 4. Send the link to anyone who needs to review the content.

For example:

    ```
    https://www.yoursite.com/about-us/?cp=AB123
    ```

The reviewer simply opens the link and sees the unpublished page exactly as it will
appear when published.

If the preview link expires or is disabled, **access is automatically denied**.

### Why Organizations Use It

The Client Preview Links plugin simplifies collaboration while maintaining security.

Benefits include:

 * No temporary WordPress accounts
 * No passwords to manage
 * No publishing content before approval
 * Faster review cycles
 * Easier collaboration with clients and stakeholders
 * Secure, time-limited preview links
 * Content remains unpublished until approved

### Ideal For

The plugin is especially valuable for:

 * Marketing teams
 * Law firms
 * Healthcare organizations
 * Financial institutions
 * Corporate communications teams
 * Universities
 * Government agencies
 * Digital agencies
 * Any organization with an approval workflow

### Built for Real-World WordPress Workflows

The Client Preview Links plugin was designed around how organizations actually create
and approve content.

Instead of forcing reviewers to learn WordPress or request access, editors can securely
share content in seconds while maintaining complete control over who can view it
and for how long.

It’s a simple solution that removes unnecessary friction from the content review
process.

### Learn More

If your organization regularly reviews content before publishing, the Client Preview
Links plugin can significantly simplify your workflow while improving security and
reducing administrative overhead.

[**Contact AZTANDC**](https://aztandc.com/contact) to schedule a live demonstration
or learn how the Client Preview Links plugin can help streamline your WordPress 
content approval process.

 
 How we deliver

## From concept through analytics and optimization

Delivery follows a defined sequence: concept, build and integrate, cloud deployment,
security, and analytics and optimization. That is the work of taking a website, 
application, or cloud system from an initial requirement into production—assembled,
released, protected, and measured.

 1.  
     Concept
 2.  
     Build & Integrate
 3.  
     Cloud Deployment
 4.  
     Security
 5.  
     Analytics & Optimization

## Visual Regression Testing

- Link: https://aztandc.com/articles/visual-regression-testing
- Published: 2026-06-16T20:05:03-07:00
- Author: aztandc

Visual regression testing helps identify unintended layout, design, and content 
presentation changes before they affect visitors. It gives website owners and teams
a clearer way to review important pages after updates, content changes, plugin updates,
theme adjustments, or development releases.

Visual regression testing is **not just a person looking** through the website manually.
It is a s**tructured process** that captures how selected pages look at a specific
point in time, then captures those same pages again after changes or updates are
made. The two sets of visuals are compared so differences can be highlighted and
reviewed.

This makes it easier to see what changed visually, even when the page still loads
and appears to function. Small changes in spacing, alignment, image display, buttons,
navigation, forms, and responsive layouts can be difficult to catch during a quick
manual review. A visual comparison helps point out those changes so they can be 
approved or corrected.

When a website changes, even small updates can affect layouts, spacing, navigation,
buttons, images, forms, and responsive views. A page may still load correctly, but
sections can shift, buttons can move, images can display incorrectly, or mobile 
spacing can become inconsistent. Visual regression testing helps surface those differences
so they can be reviewed, corrected, or approved.

This type of review is especially useful for websites that are updated regularly,
rely on multiple plugins or integrations, use custom page layouts, or include important
conversion pages such as contact forms, product pages, service pages, landing pages,
and checkout flows.

![visual_regression_testing](https://aztandc.com/wp-content/uploads/2026/06/visual_regression_testing.
jpg)

## How the Visual Review Works

The visual review starts by **capturing a reference set** of important website pages.
These reference views act as the approved version of the site before updates, content
changes, or development work are completed.

After changes are made, the same pages are captured again using the same review 
process. The **new captures are then compared against the original reference set**.
This comparison helps point out visual differences between the approved version 
and the updated version.

The review can highlight changes in layout, spacing, images, buttons, navigation,
content blocks, forms, and responsive presentation. This helps separate expected
changes from unexpected issues that may need to be corrected.

When differences are found, they are organized into a reviewable report. This allows
the team to focus on the pages and screen sizes where changes occurred instead of
manually checking every page from scratch. Some differences may be expected, while
others may need correction before the update is approved.

The review can include reference images, updated test images, difference images,
summary details, and report timestamps. This makes it easier to see what was checked,
when the review was run, and which areas may need attention.

## What We Review

A visual review focuses on the parts of a website where unexpected design or layout
changes are most likely to affect the visitor experience. This can include key pages,
shared site elements, responsive layouts, and important content areas.

 * Key page layouts before and after website updates
 * Header, footer, menu, and navigation changes
 * Mobile, tablet, and desktop presentation differences
 * Unexpected spacing, alignment, or sizing changes
 * Button, image, card, and content block display issues
 * Homepage, service page, product page, and landing page changes
 * Visual differences caused by CSS, theme, plugin, or content updates
 * Changes that should be reviewed before approval or launch

## Why Visual Testing Matters

Website updates can create unexpected visual issues even when the site appears to
be working. A visitor may still be able to access the page, but the experience may
be affected by broken-looking layouts, overlapping sections, missing spacing, misplaced
buttons, or inconsistent mobile presentation.

Visual testing helps reduce the risk of publishing updates that negatively affect
the user experience, brand presentation, readability, or conversion paths. Instead
of relying only on memory or manual spot-checking, teams can compare important pages
and quickly see where meaningful visual changes are present.

## Benefits of Visual Regression Testing

 * Captures approved page views before changes are made
 * Captures the same pages again after updates or releases
 * Helps point out visual differences between the two versions
 * Helps catch design and layout issues before they reach production
 * Reduces the chance of broken-looking pages after updates
 * Improves confidence when making website changes
 * Supports better review after plugin, theme, or CMS updates
 * Helps protect important customer-facing pages
 * Makes it easier to explain what changed during a review
 * Provides a clearer approval process before or after releases
 * Supports ongoing website quality control

## When Visual Reviews Are Helpful

Visual regression testing is useful before a website launch, after a development
release, before approving plugin or theme updates, and after major content changes.
It can also be used as part of a recurring website maintenance review to help confirm
that important pages continue to display correctly over time.

For business websites, ecommerce sites, and service-based websites, this added review
step helps protect the visitor experience. It is a practical way to identify visual
changes that could affect trust, readability, usability, or conversions.

## Clear Reporting for Review

The results can be summarized in a clear, client-friendly report that highlights
pages or screen sizes where visual differences were found. This makes it easier 
to decide which changes are expected, which need review, and which should be corrected.

Instead of reviewing every page from scratch, teams can focus attention on the areas
where meaningful differences are present. This saves time, improves communication,
and creates a more consistent review process for website changes.