Collecting Client Feedback on a WordPress Build Without Handing Out wp-admin Logins

WordPress builds have a feedback problem that has nothing to do with WordPress. The site is finished, staging is up, and now the client has to tell you what is wrong with it. Whatever route you give them — a shared doc, a thread, a dashboard login — is a route they have to learn, and the effort of reporting decides how much you actually hear. This is a guide to the route that asks them for nothing: one script tag in the site head, and the client reviews the site by clicking on it.

Why the Usual Options Go Wrong

The shared document is the most common and the worst. “The header looks weird on mobile” arrives with no page URL, no device, no browser, and no way to know whether the client means the sticky nav or the hero underneath it. Somebody on your team then spends twenty minutes turning nine of those lines into something a developer can act on, and that twenty minutes is not on any invoice.

A WordPress feedback plugin looks like the native answer and brings its own tax. It means the client needs a wp-admin account, which means creating a user, picking a role conservative enough that they cannot break the site, and then teaching a non-technical stakeholder to find their way around a dashboard built for site administrators. That is a training session before you receive a single note. It is also another plugin to keep updated, another surface for a conflict, and something that stops working the day the site migrates.

The deeper issue is that neither option captures context. The client reports what they noticed; the developer needs the page, the viewport, the browser and the console. Those get reconstructed afterwards, by asking, which is slow and often inconclusive. The wider version of this problem is not WordPress-specific, but WordPress builds hit it hardest because the client is usually the least technical person in the room.

There Is No Plugin, and That Is the Point

tapko.app loads as a single script tag served from a CDN. There is nothing to install in WordPress, which means nothing to keep updated, nothing that can conflict with the other plugins on the site, and nothing that breaks on a major WordPress release. It also means the install route is the same one you already use for analytics or a pixel — you are not learning a new mechanism.

The trade-off worth naming: because it is not a plugin, it is not managed from wp-admin. There is no settings screen inside WordPress, and the widget is configured in your tapko.app project instead. For an agency that is usually the right way round, since the client should not be configuring the feedback tool anyway.

<?php
// Child theme functions.php — outputs the tapko.app widget in the site head.
// The snippet itself is copied from your project's installation tab.

add_action( 'wp_head', function () {
    // Staging only: drop this guard once the site is live if you want
    // the widget to stay on through the warranty period.
    if ( 'staging' !== wp_get_environment_type() ) {
        return;
    }
    ?>
    <script src="https://cdn.tapko.app/dist/tapko-widget.js"></script>
    <script>
    (async () => {
        try {
            await Tapko.init({
                projectId: 'YOUR_PROJECT_ID',
                userId: 'YOUR_USER_ID'
            });
        } catch (error) {
            console.error('Error initializing tapko.app widget:', error);
        }
    })();
    </script>
    <?php
} );

Where to Put the Snippet

Any route that outputs a script tag in the head works. Pick whichever one your build already uses rather than adding a new mechanism for this.

A child theme. The version above — hook wp_head from the child theme's functions.php. This survives parent theme updates, which editing header.php directly does not.

A block theme. Block themes have no header.php to edit, so the template-file route simply does not exist. Use the wp_head hook from a child theme or a small site-specific plugin, or a header-scripts plugin.

Elementor. Site Settings has a custom code panel that takes head scripts, so nothing needs to touch theme files at all.

Divi. Theme Options has an Integration tab with a field for code added to the <head>, which does the same job.

A header-scripts plugin. If the site already has one for analytics, paste the snippet there. It is one more plugin if it does not, which is why it is last on this list rather than first.

The reports you never receive cost more than the ones that arrive badly formatted. Every step between noticing a problem and reporting it is a step where the report quietly stops existing.

What the Client Actually Does

You send them the site URL. Not a dashboard, not an invitation, not a password reset — the site. They look at it the way a visitor would, and when something is wrong they click on it and type a sentence.

What arrives on your side is the sentence plus everything you would otherwise have to ask for: a screenshot of the page as they saw it, the exact URL, the spot on the page they clicked, and the browser, operating system, viewport size and breakpoint at the moment of the report. The “looks weird on mobile” report now says which mobile, at what width, on what page.

That last part is what makes the difference on WordPress specifically. A large share of client-reported bugs on a WordPress build are a theme or plugin rendering differently at a breakpoint you did not check, and those are the ones that are hardest to reproduce from a description.

After Launch

Decide before handover whether the widget stays. It is visible to every visitor, not only the client, so leaving it on a live marketing site is a choice rather than a default. Many agencies keep it through the warranty period so post-launch issues arrive structured, then remove it — which means deleting one script tag from wherever you put it, with nothing left behind in the database.

If your development runs through a board, connect it and the reports stop needing a triage pass at all. A WordPress build under warranty generates a trickle of small issues over weeks, which is exactly the pattern where manual copying gets dropped.