Does a small site need to worry about crawling budget, what two numbers do the backend look at first?
Does a small site need to worry about the crawling budget, and what two numbers should the background look at first? In most cases, it does not need to be regarded as a bottleneck: what really blocks the crawling budget is a site with a large number of pages or frequent updates. The small site should first return to two indicators - the total number of daily crawling requests and the average response time in the search console, and stabilize these two lines before deciding whether to deal with broken links, redirect links, and bulky sitemaps.
At what scale does the crawling budget become a bottleneck?
The basis for judgment is the product of the total number of pages and the frequency of updates. For websites with a few thousand pages and content updated monthly, there is usually no lack of opportunities to be caught in a day; it is only for websites with tens of thousands of pages or more, with a large number of new entries added daily, and with filtering combinations that deep pages may not be indexed for a long time. The former is more common problem is that new pages are not indexed for a long time, which belongs to the submission and internal link issues, not quota issues.
How to read the two indicators on the back-end
| Indicator | Pronunciation | Check first when an abnormal situation occurs |
|---|---|---|
| Total number of crawling requests per day | Check whether the trend matches the content volume, whether there are sudden increases or collapses | Parameter page combinations, temporary addresses, and blocked paths |
| Average Response Time | The longer the crawling end waits, the fewer addresses it can process within the same unit of time | Database slow query, whether staticization is effective, proxy and cache configuration |
The two should be considered together: high request rate but slow response, waste is more obvious; low request rate but normal response, it is usually that the internal links do not pass on the entry.
Common three types of waste
The first is a dead link, pointing to a deleted document or a non-existent address, and the spider still comes for a visit; the second is a redirect chain, the old address jumps to a new address and then jumps again, multi-level chain jumps consume requests on the path; the third is a heavy page, the list page packs a large number of entries and scripts into the first screen. The corresponding treatment is also very direct: redirect the old address to the final address in one step, regularly remove error pages and redirect pages from the site map, and only write the paths excluded by the robots rules when needed.
What addresses should be placed in the site map?
Place only the addresses you want included, and that are currently returning normal results. Addresses that have been deleted, are pending publication, or have temporary parameters should not appear; multi-site or language versions should be maintained separately, do not mix the two sets of addresses into the same file. Pair new content with revised addresses and proactive push notifications to make discovery actions not have to wait for the next opportunity to grab it.
The priority sorting of the small station
Sort actions by profit: first clear invalid links and multi-level redirects, this kind of change can be done in one day; then check whether the addresses in the site map are all returning normally and whether they should all be included; then look at the weight of the page, how many entries and scripts the list page can load at one time; finally, it's the turn of the robots rules, clearly excluding paths that do not need to be crawled. The investment on the content side cannot be saved either - the more common problem with small stations is that there is too little content available for crawling and the internal links are too shallow, which cannot be solved by quota optimization.
Common questions
Don't we need to pay attention to crawling at all for small stations?The waste to manage is not the quota, but the dead links and redirect chains are low-cost high-yield cleaning items.
How long is considered slow response time?Focus on the relative changes before and after the revision or migration based on the self baseline, not the absolute millisecond numbers.
Is it better to have a larger sitemap?No, if the entries contain addresses that should not be included, it will only waste both the crawling and indexing quota.
** Should the robots file contain full rules? ** Only exclude paths that should not be crawled explicitly, and it's easy to block normal entries with indiscriminate blocking.
What should be done first when a new site goes live?First, make sure the internal links on the homepage, columns, and representative content are connected, and then perform active push to ensure that the new address is read on the first day.