Google can reach your page but miss its main content

When a WordPress service page looks incomplete in Google’s inspection tools, collect two things before changing settings: the initial HTML response and the rendered output. For a Dubai, Liverpool or UK service business, that comparison can show whether Google receives the actual sales copy or merely a sparse shell waiting for a script it cannot fetch.

A page URL being allowed in robots.txt only establishes that the document itself may be crawled. It does not prove that every resource needed to build the page is available. That distinction is easy to miss when the site looks perfectly normal in a visitor’s browser.

Start with the document Google receives

Open the page as a plain response, without relying on what your browser assembles after JavaScript runs. Look for the parts that carry the commercial job of the page: the service description, locations served, proof points, FAQs, pricing context where relevant and the enquiry route.

If the main copy is already in the HTML, blocked scripts may still affect layout or supporting features, but they may not explain missing core content. If the HTML contains little beyond headings, containers and script references, rendering access deserves a proper look.

Google explains that crawling, rendering and indexing are separate stages, and that it cannot render JavaScript resources it is blocked from accessing. Its guidance is to allow the resources required for rendering and then verify the rendered result. See Google’s JavaScript SEO documentation for the underlying process.

Compare the rendered page with the HTML

A WordPress page can be crawlable while an essential script is blocked. In that case, Google may fetch the page URL but receive an incomplete rendered version because the script that inserts meaningful content cannot be retrieved. Allowing the document in robots.txt is therefore not enough if the useful service content depends on separate JavaScript, API or asset paths.

Use a rendering inspection tool to compare what arrives in the source response with what appears after processing. Keep the question tight: is the content a buyer needs to assess this service present in the rendered result?

Do not turn this into a broad panic about every JavaScript file. A cookie banner script and the script responsible for your principal service copy do not carry the same weight. Audit the resources needed for the answer, not just the document URL.

Inventory the resources that build the page

Look at the network requests and blocked-resource details associated with the page. Record the full URL path, resource type and what disappears when that resource does not load. This is one of those boring details that saves time later, especially when a security plugin, CDN rule or old server configuration has been touched during a routine update.

• JavaScript files that insert or request the main page copy
• API endpoints that return service descriptions, availability or location data
• CSS files where hidden content depends on a loaded class or layout rule
• Image or media paths where the visual evidence carries an important trust claim
• Third-party scripts only where they are genuinely responsible for meaningful on-page information

An illustrative WordPress setup might load a consultancy’s service copy through a script path such as /wp-content/themes/site/assets/service-content.js. The page URL is permitted, but an inherited robots rule disallows /wp-content/themes/. A visitor sees the copy because their browser can request the file. A search renderer that follows the robots instruction may not. The page is reachable, yet its useful substance is thinner than intended.

Trace the rule that is actually controlling access

Once you have a specific blocked URL, work backwards. Check robots.txt first, then any CDN edge rules, security tooling, server restrictions and application-level behaviour that may return a different result to a crawler. It is not enough to find a rule that looks suspicious. Confirm that it applies to the exact resource path involved.

Keep this separate from index directives and canonical decisions. If a page has an indexing issue, that needs its own diagnosis. For example, a page accidentally excluded through a directive calls for a WordPress noindex response check after launch, rather than a rendering-access change.

Make the narrowest correction that permits the required resource. Avoid opening broad directories merely because one file needs access. An over-correction can create a different maintenance problem later, which is a poor trade for one missing service paragraph.

Retest the content, not just the request status

After the adjustment, request a fresh rendering check and confirm the actual page elements are present: the service explanation, supporting sections, internal calls to action and any essential structured content. A 200 response for the script is useful evidence, but it is not the finish line if the rendered page still omits the copy.

This correction does not guarantee indexing, rankings or inclusion in AI-generated results. It removes one technical obstacle to processing the content. Whether the page performs afterwards still depends on relevance, quality, competition and the rest of the site’s technical condition.

Where the wider question is whether search bots and automated systems can access the JavaScript-dependent parts of the site, our JavaScript readiness audit for AI search bots gives the adjacent checks worth considering. If the issue sits within a broader content, access and machine-readability review, an AI readiness audit of your website content can help put the rendering finding in context.

A short audit sequence worth keeping

1. Save the initial HTML response for the affected page.
2. Inspect the rendered output and identify what meaningful content is absent.
3. List the resource URLs involved in producing that content.
4. Check the exact robots and access rules affecting those URLs.
5. Allow only the resources required for the page to render properly.
6. Run a fresh rendering check and verify the service content itself.

If a service page is doing the work of explaining why someone should enquire, it should not depend on an invisible access problem left over from an old rule. Request a rendering-access check for the service content that matters to your buyers.