Google has added a clear warning for websites that use JavaScript to insert or change meta tags: avoid doing it where possible and test the implementation thoroughly when it is unavoidable.
That sounds technical, but the practical issue is simple. A service page can look perfectly normal to a customer while sending Google a missing title, an incorrect canonical URL or an instruction not to index the page.
For a builder, plumber, electrician, roofer or renovation company, those mistakes can affect the pages that explain the most valuable services and generate enquiries. They are worth checking after a redesign, plugin change, consent-platform update or switch of website supplier.
This is not a new ranking-system announcement and it is not evidence that JavaScript websites have suddenly stopped working. It is a useful prompt to verify what important pages provide before and after scripts run.
What Google changed on 31 August 2026
Google’s Search documentation update log records a 31 August addition about using JavaScript to add, change or remove meta tags. The updated supported meta tags documentation says to proceed with caution, avoid JavaScript injection or changes whenever possible, and test thoroughly when it must be used.
The important distinction is between documentation and a ranking update. Google did not announce a new core or spam update on 31 August. Its Search Status Dashboard lists the completed August spam update as the most recent ranking incident.
The advice is also consistent with Google’s established JavaScript guidance. Google can render JavaScript, but pages move through crawling, rendering and indexing. Google says server-side rendering or pre-rendering remains a good idea because it is faster for users and crawlers, while not every bot can run JavaScript.
The sensible response is therefore an audit, not a rebuild by default.
Why a trade website may change metadata with JavaScript
Many business owners never deliberately choose a “JavaScript SEO” setup. It can arrive through the tools used to build or market the site.
Common examples include:
- a single-page application that creates each service page in the browser
- an SEO plugin and a theme both managing page titles or canonical URLs
- a consent tool delaying tags until a customer chooses cookie settings
- location or service content that changes according to a visitor’s selection
- a booking, quote or lead-generation platform embedded inside the website
- a redesign that retains scripts from the previous site
JavaScript itself is not the problem. A mobile menu, gallery, calculator or enquiry form can use scripts without changing search metadata at all. The risk appears when important information in the page <head> depends on code running correctly, or when two systems disagree about what that information should be.
A technical SEO audit should separate those questions. “Does the site use JavaScript?” is too broad. “Does the correct title, robots instruction and canonical URL exist in the initial and rendered HTML?” is testable.
Check the four elements that can do the most damage
Not every meta tag deserves equal attention. Begin with the elements that affect how a page can be understood, indexed or consolidated.
1. The title element
The <title> element helps describe the page and is one of several sources Google may use for the clickable title shown in search results. Google’s title-link guidance also considers the visible main title, headings, prominent text and links.
For a roofing page, the source title should not remain “Loading…” and then rely on a script to replace it with “Roof Repairs in Southampton”. The final result may work, but the important description has become dependent on rendering and error-free code.
Compare the title with the visible heading and actual service. A unique title cannot compensate for a vague page, which is why good service-page structure still matters more than inserting extra keyword variations.
2. The meta description
A meta description can help Google form a search snippet, although Google may select other page text when it better matches the query. It is not a ranking promise or advertising space that you completely control.
Check that the initial description is useful and that JavaScript does not replace it with a blank value, site-wide default or outdated promotion. The final description should accurately summarise the page a customer will reach.
3. The robots meta tag
The robots tag can tell search engines not to index a page. This makes an accidental noindex much more serious than a weak description.
Google’s JavaScript SEO guidance warns that if Google encounters noindex, it may skip rendering and JavaScript execution. A script intended to remove noindex later may therefore not rescue the page as expected.
This can happen when staging settings reach the live site or when a launch script assumes it can change the instruction after loading. Check the homepage, core service pages and location pages immediately after a migration or release.
4. The canonical URL
A canonical tells Google which URL represents a set of duplicate or very similar pages. Google recommends putting the preferred canonical in the HTML source and making sure JavaScript does not change it. If a canonical cannot be set in the HTML, Google advises leaving it out there and setting it with JavaScript, rather than declaring one value and later changing it to another.
The full canonical guidance also recommends self-referencing canonicals and consistent internal links to the preferred URL.
A location-page system deserves particular attention. Twenty pages should not all declare the homepage as canonical, and tracking parameters should not cause scripts to generate a different preferred URL for each visitor. The guide to building useful location pages without doorway-page duplication explains the content decision; the canonical check confirms the technical implementation agrees with it.
Six warning signs to look for
You do not need to read every line of code to recognise a suspicious setup. Ask for investigation when:
- the page source contains a generic title but the browser tab later changes
- source code contains
noindexon a page intended for search - two canonical tags appear after the page finishes loading
- several service URLs initially return the same empty page shell
- titles or descriptions change after accepting or rejecting cookies
- Google Search Console reports a different canonical from the one expected across many important URLs
None of these observations alone proves that rankings or traffic were lost. For example, Google can render JavaScript and may choose a different canonical for valid reasons. They identify where evidence is needed.
The same discipline applies to AI-search claims. Google’s current guidance still centres on accessible, useful pages rather than a separate secret set of “AI tags”. Our guide to Google AI search optimisation for builders explains why clear content and crawlable foundations come first.
Test the source, the rendered page and Google’s view
One view is not enough when JavaScript changes the page.
View 1: the original HTML
Open the page, choose “View page source” in the browser and search for:
<title>name="description"name="robots"rel="canonical"
Record the exact values. This is the HTML returned before browser scripts alter it.
View 2: the rendered browser HTML
Open the browser developer tools and inspect the <head> after the page has loaded. Compare the same elements with the source. Differences are not automatically wrong, but they should be intentional and documented.
Repeat the check after accepting and rejecting optional cookies. Metadata required for search should not depend on an analytics or advertising choice.
View 3: Google’s rendered HTML
For a site you control, use Search Console’s URL Inspection tool, select Test live URL, open View tested page and inspect the HTML. Google’s rendered-source instructions explain this process.
If the live test is sound but a new page is slow to appear, do not reach automatically for an “instant indexing” plugin. The Google Indexing API has narrow eligibility rules, while ordinary service and project pages should be discovered through crawlable links, a clean sitemap and Search Console.
Test a representative set rather than only the homepage:
- the highest-value service page
- one location page
- one project or case study
- one article
- the contact or quote page
- a genuine 404 URL
Focused content optimisation should review the promise and visible copy, while this technical comparison confirms that search systems receive a consistent description of the page.
What to ask your website supplier
A business owner does not need to prescribe the code. Ask for evidence in plain language:
- Which system creates the title, description, robots rule and canonical URL?
- Are those values present in the HTML returned by the server?
- Does any plugin, tag manager, consent tool or client-side script change them?
- Can a script failure leave a valuable page blank, generic or marked
noindex? - Have source HTML, browser-rendered HTML and Google’s live test been compared?
- Is the same check included after releases and plugin updates?
The answer should identify page examples and actual values. A screenshot of a green plugin score does not show what Google receives after the complete page runs.
This is especially important where several templates exist. An electrician’s emergency-call page, planned-installation page and commercial page may share a system but need different titles and visible content. The electrician service-page guide shows how those customer needs differ; the metadata should describe each page honestly.
Fix the system in the safest order
The preferred remedy depends on the platform, but a sensible order is:
- Put essential metadata in the initial HTML. Make the title, robots rule and canonical available without relying on a browser action where the platform allows it.
- Choose one owner for each element. Remove competing theme, plugin and custom-script rules.
- Keep values consistent. Do not declare one canonical in the source and replace it with another after loading.
- Protect production from staging settings. Include an explicit release check for
noindex, test-domain canonicals and placeholder titles. - Test failure as well as success. Block a non-essential script or reject optional cookies and confirm that essential metadata remains correct.
- Deploy narrowly and verify. Check representative URLs before applying a change across every service or location page.
Do not remove useful scripts simply because they are scripts. A well-built gallery or quote form can help customers. Measure page responsiveness through the Core Web Vitals guide for construction websites and track successful enquiries through a defined lead-tracking setup. Metadata consistency, page experience and commercial measurement are separate checks that support the same journey.
A practical 45-minute audit
Choose five important URLs and create a simple table with one row per page.
For each URL, record the source and rendered title, meta description, robots value and canonical. Then complete these checks:
- confirm the live URL returns the intended content
- confirm there is one title and one clear canonical
- confirm no valuable page contains
noindex - compare the visible heading with the title
- reject optional cookies and check again
- run a Search Console live test for at least the main service page
- note who owns each fix and when it will be retested
If all values agree, record the baseline and repeat after substantial website changes. If they differ, do not edit every page manually. Find the shared template, plugin or script responsible.
A wider review of website problems that cost trades customers can then connect the technical finding with clarity, trust, speed and the enquiry path.
Final thoughts
Google’s 31 August note is a clarification, not a reason to panic about JavaScript. The durable lesson is that essential search instructions should be simple, consistent and testable.
Start with the pages that matter commercially. Compare the HTML sent by the server, the page after scripts run and Google’s rendered view. Give each title, robots instruction and canonical URL one clear source of truth.
If a trade website supplier can show those values and explain why they change, the implementation is easier to maintain. If the answer depends on a plugin score or “Google runs JavaScript”, ask for the rendered evidence.
Frequently Asked Questions
Can Google read meta tags added with JavaScript?
Google can render JavaScript and can process supported tags added correctly. Its current advice is still to avoid injecting or changing meta tags with JavaScript where possible and to test thoroughly when it is necessary.
Does this update mean JavaScript websites will lose rankings?
No. Google announced a documentation clarification, not a new ranking penalty for JavaScript sites. Problems arise from specific implementations, such as conflicting canonicals or an accidental noindex, not from the presence of JavaScript alone.
Which page should a trade business test first?
Start with the service page most closely connected to valuable enquiries, then test the homepage, a location page, a project page and the contact journey. Do not assume that a correct homepage proves every template is correct.
Should a website owner remove all JavaScript?
No. JavaScript supports useful features such as navigation, galleries, calculators and forms. Keep features that help customers, but avoid making essential metadata depend on unnecessary client-side code when the platform can provide it in the initial HTML.
