Almost certainly yes, and the useful question is which ones and who set them. This is answerable in about ten minutes without any tooling beyond the browser you already have, and doing it yourself is worth more than any report, because you will see the things a scanner categorises away.
The ten minute check
Open a private or incognito window, open the developer tools, and go to the storage or application panel. Load your home page and do not click anything. Read the cookie list with the domain column visible, then look at local storage and session storage in the same panel. Then open the network tab, reload, and look for requests going to domains that are not yours. That combination is the whole of it, and it is what an auditor would do first.
Why a scanner is not enough on its own
Automated cookie scanners are useful and they systematically miss things: cookies set only after an interaction, tags that fire on one page type, embeds on pages the crawler did not reach, and anything behind a login. They also categorise by a vendor database, which is right often enough to be trusted and wrong often enough to matter. Use one for coverage and check its output by hand on your three most important page types.
Look beyond the cookie jar
The rule that matters in Europe is about storing or accessing information on the device, not about cookies specifically. Local storage, session storage, indexed databases and device fingerprinting all count. Several tools that describe themselves as cookieless are visible in local storage, which is why the check above includes it. If it persists across visits and identifies the browser, treat it as in scope and decide later.
Check more than the home page
The home page is usually the cleanest page on a site. Check a blog post, a product or pricing page, a page with a video or map embed, and the checkout or contact form. Tags are frequently scoped to page types, and the embed that sets advertising identifiers is on the page with the demo video rather than on the front page. A cookie table built from the home page alone will be confidently incomplete.
What to do with the list
Turn it into a table with four columns: name, who set it, what it is for, and which category it belongs in. The reasoning column is the one that pays off, because it answers the question a new tag will raise in three months. Then compare the table to what your banner currently says, and the gaps are your work list. This is the shape of the worksheet on this site, and doing it on paper first is entirely fine.
Questions people ask about does my website use cookies
My site is just a few static pages. Do I still have cookies?
Possibly none of your own, and that is worth confirming because it means you may need no banner at all. Check for an embedded font, form, map or video, which is usually where they come from.
Does my hosting provider set cookies?
Some do, for routing or bot protection. Those are usually strictly necessary, but you should know they exist and be able to name them.
Do I need a paid scanner?
Not for a small site. The browser check plus a free scan for coverage is enough, and the manual check is the part that finds the interesting things.
How often should I re-check?
Whenever the site or the tag stack changes, and quarterly regardless. Sites acquire tags without anyone deciding to add one.
What if I find something I cannot explain?
Trace it from the network tab back to the script that loaded it. If it came from a vendor, ask them what it is for in writing, because you will need that sentence for the notice anyway.