Overview
KineticHub Frontend Doctor is a WordPress frontend diagnostics plugin that helps you investigate layout and interaction problems directly on the page you are viewing.
It brings five focused diagnostic tools together in one scanner:
- Viewport Doctor — detects horizontal page overflow and content clipped at the viewport edges.
- Sticky Doctor — investigates sticky elements that lack an inset, have an unsuitable scroll container, or have too little room to travel.
- Click Doctor — identifies controls whose pointer interactions are blocked by another element.
- Floating UI Inspector — detects significant collisions between independent floating interface components.
- Anchor Doctor — investigates obscured in-page navigation destinations and unresolved fragment links.
The workflow is Detect → Explain → Highlight. Run a scan, understand the findings, and use Show Elements to identify the elements involved on your page.
Frontend Doctor does not automatically modify your website. It provides browser-backed diagnostic evidence so you can decide what to change.
Install the plugin
- In your WordPress dashboard, go to Plugins → Add New Plugin → Upload Plugin.
- Select the KineticHub Frontend Doctor ZIP file.
- Click Install Now.
- Activate the plugin.
- Open Tools → Frontend Doctor to access its dashboard.
The dashboard introduces the five Doctors and provides a Scan Homepage action.
To inspect a different page, open that page on your site’s frontend while signed in as an administrator.
Run your first scan
Frontend Doctor is designed for authorized WordPress administrators. Its frontend scanner is not shown to ordinary visitors.
To scan a page:
- Sign in to WordPress with an administrator account.
- Open the frontend page you want to inspect.
- Click Scan This Page in the WordPress admin bar.
- Wait for the five Doctors to finish.
- Review the results in the diagnostic panel.
The lightweight launcher is available to authorized administrators. The diagnostic runtime loads when you request a scan rather than running continuously on every pageview.
Important: A scan examines the current page in its current browser state. Its findings can depend on the viewport width, scroll position, rendered content, open menus, and other interface conditions.
For a mobile layout issue, scan at a mobile width. For an interaction issue, reproduce the relevant interface state before starting the scan.
Understanding scan results
Each Doctor has its own result. When a Doctor detects a supported condition, Frontend Doctor displays a finding with a plain-language explanation and relevant technical evidence.
A finding may identify one element or several related elements. For example, Click Doctor can identify both a blocked button and the element covering it.
Severity and confidence
Severity describes the significance of the reported condition. Confidence describes how strongly the available evidence supports the finding.
These are different concepts. A finding can have a meaningful impact without Frontend Doctor being able to identify every contributing element with certainty.
You may encounter labels such as:
- Warning — a condition that may affect usability or expected frontend behavior.
- Notice — information worth reviewing without treating it as the same level of problem as a warning.
- Confirmed — the reported condition is supported by the browser measurements used by the check.
- Likely — the available evidence points to a probable contributor or explanation.
- Context — supporting information that should not be interpreted as a confirmed defect.
Read the explanation and technical details together. A label alone cannot determine whether a behavior is intentional on your site.
No issues detected
No issues detected means that the completed checks found no reportable conditions within their supported scope.
It does not mean the page is perfect or free of every layout, interaction, accessibility, or performance problem.
Incomplete
Incomplete means a Doctor could not complete all the work required for a complete result.
An incomplete check must not be interpreted as a clean result.
Scan failed
Scan failed means the Doctor could not complete its diagnostic operation.
If a check is incomplete or fails, try Rescan. If the problem persists, note the page state and check the browser console for relevant errors.
Viewport Doctor
Viewport Doctor investigates horizontal layout problems at the current browser width.
It distinguishes between a page that can scroll sideways and content that extends beyond an edge but cannot be reached.
Horizontal page overflow
A page has horizontal overflow when its content makes the document wider than the available viewport, allowing the page to scroll sideways.
This can be caused by a wide image, table, block, grid, flex item, fixed width, minimum width, margin, or transform.
Example: A content block has a minimum width greater than a phone’s viewport. Visitors can scroll the entire page horizontally even though the layout was intended to fit the screen.
Viewport Doctor measures the actual document width and looks for elements that may contribute to the excess.
Clipped content
Clipped content extends beyond an edge of the viewport but is hidden rather than remaining reachable through horizontal scrolling.
Example: A container hides horizontal overflow while an important button extends beyond its visible area. Visitors cannot reach the entire control.
This is different from horizontal page overflow. Hiding the scrollbar does not necessarily resolve the underlying layout problem.
How to investigate a Viewport finding
- Open the finding and read its explanation.
- Use Show Elements to locate the relevant element.
- Open Technical details to review the reported measurements and layout properties.
- Check the element’s width, minimum width, margins, transforms, and containing layout at the affected breakpoint.
- Make the appropriate change in your theme, block settings, or CSS.
- Click Rescan to measure the page again.
Tip: Avoid applying overflow-x: hidden to the entire page simply to conceal unwanted horizontal scrolling. It may hide content that visitors need to see or interact with.
An intentionally clipped visual effect or horizontal carousel may be valid. Review the reported condition in the context of your design.
Sticky Doctor
Sticky Doctor investigates elements using CSS sticky positioning that do not have the conditions needed for the intended behavior.
Sticky positioning depends on the element’s insets, scroll container, containing block, and available travel space.
No sticky inset
A sticky element needs an inset on its relevant axis to establish where it should stick.
For example, an element using sticky positioning for vertical scrolling generally needs an appropriate top or bottom value.
Sticky Doctor can report an element whose sticky positioning has no inset on either axis.
Scroll constraint
A sticky element can be constrained by an ancestor scroll container rather than the page itself.
If that ancestor has no usable scroll range, the sticky element may not behave as the site owner expects during page scrolling.
Sticky Doctor identifies the constraining element when the browser evidence supports that conclusion.
Important: An ancestor’s overflow setting is not automatically a bug. A scrollable ancestor can be a valid sticky container. The relevant question is whether the actual scroll context provides the movement needed for the intended behavior.
No travel
A sticky element may have a valid inset and scroll context but too little room to travel inside its containing layout.
For example, a sticky sidebar inside a short wrapper may have almost no available space in which to move.
How to investigate a Sticky finding
Use Show Elements to inspect the sticky element and any relevant container.
Review the technical details, then check:
- The intended scroll direction and the corresponding inset.
- The ancestor that establishes the scroll context.
- Whether that container has a usable scroll range.
- The height or width of the containing block.
- The space available for the sticky element to move.
After adjusting the layout, reproduce the original scroll behavior and run Rescan.
Click Doctor
Click Doctor investigates eligible controls that appear on the page but cannot receive a pointer interaction because another element is in the way.
A control may look normal while the browser sends the interaction to a transparent overlay, decorative layer, or another positioned element.
Click Doctor uses browser hit testing to investigate what is actually receiving the interaction.
Blocked controls
A blocked control is an eligible button, link, or other interactive element whose relevant pointer interaction is intercepted by another element.
Example: A transparent overlay remains above a Subscribe button after an animation. The button is visible, but clicking it interacts with the overlay instead.
Click Doctor can identify the affected control and the element responsible for the obstruction.
Intentional overlays and modal interfaces
Not every blocked background control is a defect.
For example, an open modal may intentionally prevent interaction with the page behind it. Frontend Doctor accounts for supported modal states instead of automatically treating every covered background control as a problem.
How to investigate a Click finding
- Open the finding and review the identified control.
- Click Show Elements to locate the control and the element covering it.
- Review the relevant positioning and pointer-interaction evidence.
- Check the overlay’s purpose, stacking behavior, positioning, and pointer-event settings.
- Correct the responsible layout or component if the obstruction is unintended.
- Run Rescan.
Click Doctor does not submit forms, click through user workflows, or test whether a payment or other business process succeeds. Its purpose is to investigate the browser’s observable interaction path to eligible controls.
Floating UI Inspector
Floating UI Inspector investigates significant collisions between independent floating interface components.
These components can include chat launchers, back-to-top buttons, floating contact controls, and other viewport-fixed widgets.
A collision becomes relevant when one floating component covers a substantial part of another component’s usable surface.
Floating component collisions
Example: A chat launcher and a back-to-top button are positioned in the same bottom corner. The chat launcher covers most of the back-to-top button, preventing visitors from using both controls independently.
Floating UI Inspector examines the rendered surfaces and browser hit-testing evidence to identify supported collisions.
It focuses on independent floating components rather than treating every overlap on the page as an error.
How to investigate a floating UI collision
- Open the Floating UI finding.
- Use Show Elements to highlight both components and their relationship.
- Review their positions, dimensions, and responsive offsets.
- Identify which plugin, theme component, or custom code controls each widget.
- Adjust their placement so both remain usable.
- Test at desktop and mobile widths, then run Rescan.
When Floating UI Inspector and Click Doctor identify the same underlying collision, Frontend Doctor can present it as one finding rather than duplicating the issue.
What Floating UI Inspector does not report
Floating UI Inspector is not a general rule that floating elements must never overlap page content.
Sticky headers, modal dialogs, banners, and other interfaces may intentionally cover part of the page.
It also does not treat every small overlap or partly off-screen widget as a confirmed defect.
Anchor Doctor
Anchor Doctor investigates in-page navigation and the destination reached by a fragment link.
It focuses on supported cases where a destination is obscured after navigation or a link points to a missing destination.
Obscured anchor landing
A fixed or sticky header can cover the heading or readable content that a visitor has just navigated to.
Example: A visitor clicks Pricing in a table of contents. The page scrolls to the Pricing section, but the section heading lands underneath the fixed header.
Anchor Doctor checks the browser’s actual landing and the content covered by the relevant interface element.
It does not simply assume that every anchor near a sticky header is obscured.
Unresolved fragment links
A fragment link points to a destination within the current page.
Anchor Doctor can identify supported cases where a link in a qualifying group of in-page links points to a destination that does not exist.
Example: A table of contents contains working links to several sections, but one link points to a section ID that has been renamed or removed.
How to investigate an Anchor finding
For an obscured landing:
- Follow the in-page link as a visitor would.
- Run Scan This Page after the browser reaches the destination.
- Open the Anchor Doctor finding.
- Use Show Elements to inspect the destination and the covering element.
- Review the header positioning and the page’s scroll-margin and scroll-padding behavior.
- Make a targeted adjustment and test the navigation again.
For an unresolved fragment, check that the fragment in the link matches an existing destination ID or named anchor on the page.
Important: Anchor Doctor relies on the browser’s actual navigation and rendered position. If the page has moved away from the landing or a script controls navigation in a way the Doctor cannot verify, it may not report an obscured landing.
Show Elements
Show Elements connects the diagnostic finding to the actual frontend page.
Depending on the finding, it may highlight one element or visualize the relationship between several elements.
For example, a Click Doctor finding may show both the blocked button and the overlay covering it. A Floating UI finding may show both overlapping widgets.
How it works
- Click Show Elements on a finding.
- Frontend Doctor displays the relevant visualization on the page.
- If the target is entirely outside the visible area, the page may scroll vertically to bring it into view.
- Click the same control again to turn the visualization off.
Only one finding’s visualization is active at a time. Selecting another finding replaces the previous visualization.
The drawing is temporary. It does not save changes to your page or prevent normal interaction with the elements underneath it.
Note: Showing an element after the layout has changed may require the Doctor to check whether the original finding is still current. If the page has changed significantly, use Rescan.
Technical details
Each finding provides a plain-language explanation. Technical details gives you the additional information needed for closer investigation.
Depending on the Doctor, this may include:
- The diagnostic rule associated with the finding.
- The affected element and related elements.
- Relevant browser measurements.
- Computed CSS properties.
- Evidence about scrolling, positioning, clipping, or hit testing.
- The viewport and page state relevant to the result.
Technical details are especially useful when investigating a theme, adjusting a Gutenberg layout, or preparing a reproducible report for a developer.
Copy Details
Use Copy Details to copy a finding’s technical information into a text editor, support ticket, or message.
The copied information identifies the relevant diagnostic check and provides evidence that can help another person investigate the issue.
Frontend Doctor is designed not to include the page’s own prose or URL query-string content in copied diagnostic details.
Before sharing a report: Review the copied information, especially when working on a private, staging, or client website.
Rescan and outdated results
Frontend Doctor measures the page at the time you run the scan.
If you fix a problem, open or close an interface component, or change the viewport, the previous results may no longer represent the current page.
Click Rescan to perform a new diagnostic pass.
A rescan creates a new result for the current page state. It does not combine old and new findings or create a permanent scan history.
Resizing the browser
A substantial viewport change can make earlier findings outdated.
For example, a desktop layout may fit correctly while the same layout produces horizontal overflow on a phone-width viewport.
If the panel indicates that its results are out of date, use Rescan before acting on them.
Recommended troubleshooting workflow
A reliable workflow is to investigate one supported condition at a time:
- Reproduce the issue. Open the affected page at the relevant width, scroll position, and interface state.
- Run a scan. Use Scan This Page to collect current browser evidence.
- Read the finding. Understand the observed condition and the reported confidence.
- Show the elements. Locate the affected component and any related elements.
- Review technical details. Identify the properties or measurements relevant to the issue.
- Make a targeted change. Use your WordPress settings, block controls, theme, or custom CSS.
- Rescan. Confirm whether the condition has changed or disappeared.
When investigating a responsive issue, repeat the process at the affected breakpoints.
When investigating an interaction issue, make sure the relevant menu, overlay, or other component is in the state where the problem occurs.
Privacy and site safety
Frontend Doctor runs its diagnostics in the browser when an authorized administrator requests them.
The diagnostic workflow does not require uploading your page to a remote analysis service, and the plugin does not maintain a persistent scan history or send diagnostic telemetry.
A scan is read-only. Frontend Doctor does not automatically click controls, submit forms, open menus, navigate, or rewrite your site’s content.
Show Elements is a deliberate user action that may scroll vertically to an off-screen element so you can inspect it.
The scanner itself is not intended to become a source of the layout or interaction issues it is measuring.
Accessibility and reduced motion
Frontend Doctor’s diagnostic panel supports keyboard interaction.
Its controls can be reached using the keyboard, and the panel can be closed with Escape.
The temporary Show Elements visualization is not intended to intercept pointer interaction with the page underneath it.
When your operating system requests reduced motion, Frontend Doctor respects that preference, including when bringing an off-screen element into view.
Important limitations
Frontend Doctor is a focused diagnostic utility, not a certification tool.
Current page only
Frontend Doctor scans the page you are viewing, not the entire website.
Other pages, templates, screen widths, and interface states may produce different results.
A point-in-time scan
The result reflects the browser state when the scan was performed.
If the page changes afterward, the original result may become outdated. Use Rescan to inspect the new state.
No automatic fixes
Frontend Doctor does not rewrite CSS, modify theme files, disable plugins, or apply repairs automatically.
It helps you identify and understand supported conditions so you can decide how to resolve them.
Not a complete accessibility or performance audit
The five Doctors investigate specific layout and interaction conditions.
A clean scan does not certify accessibility compliance, browser compatibility, SEO, performance, or overall website quality.
Embedded component boundaries
Some iframe and Shadow DOM content cannot be inspected internally. Frontend Doctor may treat these components as individual elements and report only what the browser evidence supports.
Intentional behavior
Carousels, modal overlays, clipped visual effects, and other interfaces may intentionally use behavior that resembles a problem.
Review findings in the context of your design and intended user experience.
Browser-specific navigation
Browsers can differ in how they align certain legacy in-page anchors.
Anchor Doctor accounts for supported differences in native fragment navigation. Some uncommon legacy named-anchor layouts may still fall outside its diagnostic coverage, particularly in WebKit-based browsers.
Administrator and visitor views
A page can render differently for a signed-in administrator and a logged-out visitor.
The WordPress admin bar, authentication-dependent content, and other administrator-only elements can affect the layout. Frontend Doctor excludes WordPress’s own admin chrome from relevant findings, but you should still consider differences between the administrator and public views.
Troubleshooting
Scan This Page is missing
Check that:
- KineticHub Frontend Doctor is installed and activated.
- You are signed in with an administrator account.
- You are viewing the site’s frontend rather than an unrelated admin screen.
- Your WordPress admin bar is available on the page.
If the control is still missing, temporarily test with other plugins disabled on a staging site to investigate a possible integration conflict.
A scan does not open
Reload the page and try again.
If the problem persists, open the browser’s developer console and check for JavaScript errors or failed asset requests.
Test on a staging site when investigating plugin or theme conflicts.
No issues are detected, but the page still looks wrong
Check that you scanned the page at the viewport and interface state where the problem occurs.
Review the individual Doctor statuses. A completed clean check is different from an incomplete or failed check.
Frontend Doctor does not cover every possible frontend issue. You may still need a manual inspection with browser developer tools.
A finding disappears after resizing
The layout or available space may have changed at the new breakpoint.
Run Rescan to obtain results for the current viewport rather than relying on an earlier measurement.
Show Elements does not highlight what I expected
The page may have changed since the scan, or the relevant element may no longer be in the same state.
Run Rescan and try Show Elements again.
Some findings describe a page-level condition without a single identifiable culprit. In these cases, Frontend Doctor may have limited element-level visualization.
Two plugins have floating controls in the same corner
Run Floating UI Inspector with both controls visible.
Review the finding, identify the two components, and adjust their positions or responsive settings so neither prevents access to the other.
A sticky element does not stick
Review Sticky Doctor’s result and the element’s technical details.
Check the inset, relevant scroll container, available scroll range, and containing block. A sticky element may have valid CSS but insufficient space to travel.
An anchor link lands under the header
Follow the link, then run Anchor Doctor at the resulting destination.
Review the covering header and destination. Check whether the intended layout needs an appropriate scroll margin, scroll padding, or header adjustment.
Frequently Asked Questions
Does Frontend Doctor fix the issues it finds?
No. It detects, explains, and highlights supported conditions. You make the changes using WordPress, your theme, the relevant plugin, or custom code.
Does it scan every page on my website?
No. It scans the current frontend page and current rendered state. Open another page and start a new scan to inspect it.
Can I use it with Gutenberg and other WordPress plugins?
Yes. Frontend Doctor examines the browser’s rendered page rather than requiring a particular block or theme.
Third-party components can still create inspection boundaries, and results depend on the actual page state.
Can I scan a mobile layout?
Yes. Set the browser to the width you want to investigate and run a scan. You can also use your browser’s device-emulation tools when testing responsive layouts.
Does the plugin run for visitors?
No. The diagnostic controls and runtime are intended for authorized WordPress administrators. Visitors do not receive the frontend scanner.
Does it change the content of my website?
No. A scan does not save changes to your page, theme, blocks, or plugin settings.
Show Elements adds a temporary visualization and may scroll to an off-screen element when you request it.
Can I send a finding to a developer?
Yes. Use Copy Details to share the relevant diagnostic information.
It also helps to include the affected page, browser, viewport width, and the steps needed to reproduce the issue.
What does No issues detected mean?
It means the completed checks found no reportable conditions within their supported scope.
It does not mean the entire page has been tested for every possible frontend problem.
Does Frontend Doctor replace browser developer tools?
No. Frontend Doctor helps identify and explain focused diagnostic conditions. Browser developer tools remain useful for inspecting styles, testing fixes, reviewing network activity, and investigating problems outside its scope.
Support
If Frontend Doctor reports an unexpected result or fails to complete a scan, gather the following information before requesting support:
- Your WordPress version.
- The browser and browser version.
- The affected page and viewport width.
- The steps needed to reproduce the problem.
- The relevant Copy Details output, when available.
- Any browser console errors associated with the scan.
Review the copied diagnostic information before sharing it, particularly when investigating private or client websites.
For product information and support, visit GetKineticHub.
Live Playground
Want to try Frontend Doctor before installing it?
Launch the interactive Diagnostic Lab in WordPress Playground. It runs the real KineticHub Frontend Doctor 1.0.0 plugin on a prepared page with five deliberate frontend problems, so you can test the full Detect → Explain → Highlight workflow.