SEO Page Generator Debug Log
The SEO page generator gives you a comprehensive logging feature so you can analyze the content of a page created by the server-side rendering (SSR) process. The log includes:
-
The content of the HTML page after it's been processed
-
Timings
-
Memory usage
-
CPU usage
-
A breakdown of the subrequests made, such as to JavaScript and CSS files
-
Console messages, warnings, and errors, if present
The debug log helps developers and SEO experts check that the page content served to search engine crawlers matches what human users see, and is error-free.
Viewing the SEO Page Generator Debug Log
The main way to generate debug logs from the SEO page generator is to add the seodebug=T parameter to a SuiteCommerce web store page URL and then view its source.
To view the debug log provided by the SEO page generator:
-
Go to the URL of the page you want to debug.
-
Right-click on the page and select View page source.
-
Modify the page's URL and append
?seodebug=Tas a URL parameter. If it's the only URL parameter, you need to use a question mark (?) first. If there are other parameters, use an ampersand (&). For example, your URL will look something similar to the following:view-source:www.mywebstore.com/Salida-Backpack?seodebug=Tview-source:www.mywebstore.com/Salida-Backpack?color=red&seodebug=T -
Select Enter to reload the page with the new parameter added.
-
After the page loads, scroll down to view the debug log from the SEO page generator. It will look something similar to the following:
<!-- Debug output: [09:12:15.780] [ +0 ms ] Requested URL with SEO generator relevant params: https://www.mywebstore.com/Salida-Backpack?seodebug=T [09:12:15.780] [ +0 ms ] Source URL: https://www.mywebstore.com/scs/shopping.ssp#/Salida-Backpack?seodebug=T [09:12:15.780] [ +0 ms ] Rewrite Path: /s.nl?sitepath=/scs/shopping.ssp [09:12:16.099] [ +319 ms ] Generated the frame page for the requested URL [09:12:22.215] [ +6116 ms ] Got a response from Prerender V2 [09:12:22.216] [ +1 ms ] Memory usage: 30.523438MB [09:12:22.216] [ +0 ms ] CPU usage: 0.650000s [09:12:22.216] [ +0 ms ] Sub request total: 5.277000s ... -->
Testing the New SEO Page Generator (Version 2)
Starting in the first quarter of 2026, SEO Page Generator Version 2 (V2) rolls out automatically. If your site wasn't an early adopter, you can preview V2's execution using the seodebug parameter. Instead of seodebug=T, use seodebug=V2 in your URL as in the following example:
view-source:www.mywebstore.com/Salida-Backpack?seodebug=V2
This enables you to review how V2 renders and logs your page content without changing your site's default SSR engine.
Some sites on Version 1 ran into JavaScript syntax errors if their extensions used modern JavaScript features, which caused business logic to break. With V2, all JavaScript code runs fully during the rendering process. However, sites with existing JavaScript errors could still have problems if any of these issues occur during execution:
-
JavaScript runtime errors, such as undeclared variables or faulty logic
-
Using external scripts or logic that should be excluded from prerendering (such as chat widgets with infinite polling, human-interaction trackers, or some payment processor integrations) can prevent the site from fully loading
To maximize the benefits of V2, make sure your site's free of runtime errors and that you've excluded any non-essential, disruptive scripts from prerendering, as described in SEO Page Generator Best Practices.
Troubleshooting Tips
Avoid Cached Responses
After a URL has been requested from the page generator, it will be cached. That means that if you make a change and then request the same URL, you may get a cached version that doesn't reflect your changes. To work around this, add another URL parameter to make the request unique without changing the page content. To do this, you can use the preview parameter and give it a new value each time you make a request. For example:
view-source:www.mywebstore.com/Salida-Backpack?seodebug=T&preview=1234
The next time you request the page, you should change the number, for example, by incrementing it by 1 from 1234 to 1235.
Use a Fresh Browsing Session
The SEO page generator won't run in some cases. The most common is when you use a browsing session where the user is logged in or recognized. If the page generator doesn't run when requested, it returns a log describing the reason. For example:
[04:05:20.169] [ +253 ms ] SEO page generator wasn't executed: bypassSeoGeneratorAfterSspForward: notGeneratable=false incorrectStatusOrContentForSeoGenerator=false bypassSeoGeneratorForRecognizedOrLoggedIn=true bypassSeoGeneratorSwitchEnabled=false, url=https://www.mywebstore.com/Salida-Backpack/?seodebug=T
In this case, bypassSeoGeneratorForRecognizedOrLoggedIn returns true, which means that the user is currently logged in or has logged in recently.
To avoid this, use a fresh browsing session, such as your browser's incognito mode, or try a different browser.
Investigate Console Logs for Errors
Because the page generator uses SSR for JavaScript, there may be errors when it's parsed and executed. These will be returned in the debug log and may mean there's a problem with your code. The most common problems happen when your JavaScript uses features newer than ECMAScript 2024. This is because the page generator doesn't support them and will throw errors. When this happens, you'll see a standard JavaScript error. For example:
[03:52:57.868] [ +0 ms ] Logs generated by console.log():
[ +0 ms ] jQuery.Deferred exception: Cannot read properties of undefined (reading 'value')
TypeError: Cannot read properties of undefined (reading 'value')
at Object.fn (https://www.mywebstore.com/scs/extensions/shopping_7.js?t=1757929882349:15379:33)
at https://www.mywebstore.com/scs/javascript/shopping.js?t=1757929882349:1:351589
at ie.gt (https://www.mywebstore.com/scs/javascript/shopping.js?t=1757929882349:1:9606)
...
In this example, the error occurred because of a runtime error.
When investigating logs, the page generator may also include generic console logs and warnings. You should check each one but note that they may not indicate a problem or error.
Investigate Sub-Request Errors
The debug log provides a breakdown of every additional resource requested when the page loaded, including the status code and how long the page took to load.
[09:12:22.217] [ +1 ms ] Details of 15 sub requests:
GET https://www.mywebstore.com/scs/public/shopping.environment.ssp?lang=es_AR&cur=&X-SC-Touchpoint=shopping&t=1714685769941 [status 200]
Requested at 2024-08-06T16:12:16.216Z and responded by 2024-08-06T16:12:16.912Z (which took 696ms)
GET https://www.mywebstore.com/scs/public/shopping.environment.shortcache.ssp?X-SC-Touchpoint=shopping&t=1714685769941 [status 200]
Requested at 2024-08-06T16:12:16.217Z and responded by 2024-08-06T16:12:18.417Z (which took 2200ms)
GET https://www.mywebstore.com/scs/languages/shopping_en_US.js?t=1714685769941 [status 200]
Requested at 2024-08-06T16:12:16.217Z and responded by 2024-08-06T16:12:16.313Z (which took 96ms)
...
You should check each status code for any error status codes, such as 404s and 500s.
Three Dots in Main Div When Viewing Source
If you use the view-source URI without the seodebug=T URL parameter, it won't trigger the page generator by default. That's because if you view the page's source HTML without either running the SPA JavaScript or triggering the page generator, you'll be served the SSP 'frame page'. This is the barebones HTML that makes up the page before resources load and JavaScript runs.
The frame page can be identified by three dots (an ellipsis) in the main div. For example: <div id="main" class="main">...</div>.
This is served by default so that at least some content is returned, with the expectation that it'll be replaced later with the actual page's content after the browser or page generator renders it.
Therefore, receiving the three dots does not necessarily indicate an error since it's the default response from the server when the page generator is bypassed. It may indicate an error if it's served in scenarios when fully rendered content should have been served, such as in response to a search engine crawler or when using seodebug=T.
Note that, in this scenario, other parts of the page won't be fully rendered or executed since it's just the frame page. For example, if the frame page is served, it's unlikely that title or meta tags have been produced yet, since they're usually produced during rendering.
Other Ways of Viewing Prerendered Content
SEO page generator content can be viewed without including outputs generated by the debug log. This may be preferable since it'll show you the exact content that's generated and served to search engine crawlers.
-
Search Engine Tools - many search engines provide tools to website owners so that they can analyze their site, including looking at specific pages that they have indexed. For example, Google's URL Inspection Tool can provide you with the HTML it received and a screenshot.
-
User Agent Spoofing - web browser and CLI developer tools let you request page content using a custom user agent string. If you set this user agent string to one that a search engine crawler uses, it should trigger the page generator to run.