Search Console shows you what Google chooses to tell you about your site. Server logs show you what Google actually does: every request, at what time, to which page and with what result. It's the most direct source for understanding how you're being crawled, and almost nobody looks at it.
You don't need a technical team or paid software. With a text file and a few commands, or with Search Console's crawl report, you can draw useful conclusions even on a small site.
What access logs are
Your server writes to a file (usually called access.log) one line for every request it receives, whether it comes from a person, a Google robot or any other bot. Each line typically includes the IP address, date and time, the page requested, the response code (200, 301, 404, 500...), the size and the user agent, which is the name the requester identifies itself with.
On shared hosting there's usually an option in the control panel to download logs, and sometimes they're only kept for a few days or weeks. If you use a CDN, part of the requests may be recorded there rather than on your server. Also bear in mind that IP addresses are personal data: don't share them unnecessarily.
What they tell you about how Google crawls
By filtering the lines whose user agent contains Googlebot, you can answer concrete questions. Which pages does it visit most? How often does it come back to the important ones? Does it spend its time on useless addresses, such as filters, parameters or internal search pages?
For example, grep Googlebot access.log pulls out its visits, and with a bit more filtering you can count how many times it requested each address. If a block of low-value URLs takes most of the visits, something in your structure is wasting its time.
Errors and ignored pages
Look at the response codes the bot receives. Many 404 responses point to broken internal or external links, or deleted pages with no redirect. 5xx codes (such as 500 or 503) are server errors: if they repeat, Google may slow down its crawling. Chains of 301 or 302 redirects also waste visits.
The opposite matters too: if an important page is in your sitemap but never shows up in the bot's records for weeks, it may lack internal links or be buried deep. A clear example is a service page that no other page links to. Note that Google doesn't crawl every page equally often, so one isolated absence proves nothing; look for patterns.
How to tell it's really Googlebot
The user agent can be faked, and many bots do it to get in. To verify a suspicious one, Google recommends two steps. First, a reverse DNS lookup of the IP: it should resolve to a domain such as googlebot.com or google.com. Second, a forward DNS lookup of that name, which must return the original IP. On Linux, with host, that takes two commands.
Google also publishes official lists of its crawlers' IP ranges, which you can check against. Do this before drawing conclusions or blocking anything, because among the supposedly Google visits there may be other robots.
What to do with what you find
Fix the 404s that receive links: restore the page or redirect it with a 301 to the closest match. Resolve 5xx errors by talking to your hosting provider. Shorten redirect chains so they point straight at the final destination. Add internal links to the important pages the bot ignores and check they're in the sitemap.
If the bot wastes time on useless URLs, consider blocking those patterns in robots.txt or stopping them from being generated, taking care not to block anything you want to rank. And repeat the review now and then to see whether your changes had an effect.
Frequently asked questions
Do I need paid tools to analyse logs?
No. For a small or medium site, the logs downloaded from your hosting and a text editor or spreadsheet are enough. Specialised tools help with very large volumes, but they aren't a requirement.
What if my hosting doesn't give me access to logs?
Then you can use Search Console's crawl stats report, which summarises Google's requests, their response codes and how they change over time. It's less detailed but covers the essentials.
How often should I review them?
It depends on your site's size and how often it changes. A quarterly review is enough for many small sites; it's also worth doing after a migration, a redesign or a drop in traffic.