Verba optimization settings: headings, breadcrumbs, cleanup

This article covers functionality available to customers on the Pro version.

VerbaTheme OptionsGeneralOptimization covers three things: document structure, where the breadcrumb trail comes from, and cleaning up what WordPress loads on every page.

#Headings

Gives a page with no visible title a hidden H1, so every page has exactly one.

Every page is supposed to have one top-level heading. It describes the document to browsers, to screen readers, and to anything else reading the structure rather than the design. A page built entirely out of sections can easily end up with none, or with three.

Turn it off only when something else already places the H1, for example a page built in Elementor with its own heading widget at the top.

#Breadcrumbs

Only one setting lives here: where the trail comes from.

What builds the breadcrumb trail. The theme mechanism, or an active SEO plugin. Plugin options appear in the list once one of them is installed.

Keeps the trail visible on narrow screens.

Paints plugin breadcrumbs like the rest of the theme. Only shown when the source is a plugin.

Everything else about breadcrumbs, meaning turning them on at all, the separator, the home link, and trimming long trails, is in AppearanceCustomizeGeneralBreadcrumbs. The panel says so and links you there.

This is the clearest example of a rule the settings follow throughout: one thing, one owner. Breadcrumbs belong to the free theme, so their visibility stays in the Customizer, and only the part that needs Pro, reading a trail out of an SEO plugin, sits here.

On a phone the trail takes a whole line above the title and adds very little. Turning it off there is a reasonable default, not a compromise.

#Performance

Each toggle removes something WordPress adds to every page whether you use it or not. Removing them will not transform a slow site, but there is no reason to ship code nobody asked for.

Drops the emoji detection script and styles. Emoji you type still display, because browsers render them natively.

Drops the script that lets other WordPress sites embed your posts in a card. Embeds you paste into your own posts still work.

Removes the compatibility shim for jQuery code written years ago.

Removes rarely used tags WordPress puts in the document head.

Removes the RSS and Atom link tags from the head. The feeds themselves stay reachable at their URLs, so subscribers are not cut off.

Stops loading jQuery entirely.

The last one is the only risky switch on this page. Plenty of plugins still expect jQuery on the front end, and when it is missing they fail silently: a slider stops sliding, a form stops submitting. Turn it on, then click through your site with the browser console open and look for errors before you leave it on.

#What this is not

This is basic hygiene, not a performance strategy. If your pages are slow, the causes are almost always elsewhere: no page cache, oversized images, a slow host, or a stack of third-party scripts. Those are covered in the performance tutorial.

Will removing feed links break RSS subscribers?

No. The feed URLs still work; readers that already know them keep working. What disappears is the automatic discovery tag, so a browser or reader can no longer find the feed on its own.

How do I know if a plugin needs jQuery?

Turn the jQuery toggle on, open a page that uses the plugin, and check the browser console. $ is not defined or jQuery is not defined is the answer. Test the pages with sliders, forms, and popups, since those are the common users.

Do I still need an SEO plugin with these settings on?

Yes, if you want control over titles, descriptions, and sitemaps. These settings handle document structure and cleanup, not metadata.

Last updated 9 Sep 2026

Was this article helpful?

FIND THE ONE THAT FITS YOUR PROJECT

Import a demo, swap the content, adjust the layout. Modern WordPress under the hood, fast even when the site fills up.