Technical SEO
& performance audit
in Burbank

A catalogue of two hundred items can produce tens of thousands of addressable pages. Colour, size, sort order, page number, and every combination of them. Nobody decided to publish those pages. The system generates them.

Crawlers find them through links. A filter rendered as a normal link is a road sign. Follow enough of them and a crawler spends its time on near-identical listings while the pages that matter wait.

The first decision is which combinations deserve to exist as pages at all. Usually a small set. A category, sometimes a category plus one high-demand attribute. Everything beyond that is a view, not a page.

Views should be reachable without creating crawlable addresses. Handle them so the state changes without producing a new linked URL, or mark the generated addresses clearly as secondary.

Pagination needs its own answer. Each page of a list should be distinct, self-canonical and reachable. Pointing every page back to the first tells the crawler the rest do not exist, and items deep in a list then never get found.

Sort order is the easiest win. Ascending and descending views of one list are the same content twice. There is no reason for both to be indexable.

Watch for the infinite case. A date filter with no upper bound, or a calendar that always offers next month, produces a corridor with no end. Crawlers will walk it.

Measure this from the server log rather than from a crawl tool. The log shows what was actually requested and how often. A site where most crawl requests land on filtered listings has already answered the question of why new pages take weeks to appear.

In Burbank, technical SEO costs from ~$600 for the audit with fixes, or ~$800 once speed and security work are added. A focused audit with a remediation plan takes three to five weeks, as listed on this page. We begin at the server: what it answers, how fast, and how honestly.

A crawler learns a lot before it reads a word. Status code, response time and headers tell it whether to index, retry or slow down.

Server errors cost the most. When a host answers with 500, 503 or 429, Googlebot lowers its crawl rate for that host. A few minutes of errors during a nightly deploy can show up in the Crawl stats report. If the errors persist, URLs that keep failing drop out of the index.

Planned maintenance has a correct answer. Return 503 with a Retry-After header. Keep it to hours. A maintenance page served with 200 gets indexed as the content of every URL it replaced.

Missing pages should say so. A 404 or 410 tells Google to drop the URL, and both work. A 200 with an error message inside is a soft 404. It wastes a fetch every time.

Response time is its own signal. Crawl stats shows the average for Googlebot's requests. When that average climbs, crawl volume falls to match. Slow uncached pages, such as internal search, often drag down the figure for the whole host.

Conditional requests help large sites. A server that answers If-Modified-Since with 304 Not Modified saves the download for unchanged pages. Many stacks send no Last-Modified header at all. Then every recrawl is a full fetch.

Bot protection is a newer failure. A firewall rule that answers Googlebot with a 403 or a script challenge blocks crawling without a single visible error. Verify the crawler by reverse DNS or Google's published IP ranges before allowlisting it. User-agent strings are faked all the time.

Robots.txt has a special status here. If the file itself returns a 5xx, Google pauses crawling of the site until it can read the rules again. The host status panel in Crawl stats shows failed robots.txt fetches, DNS errors and connection failures separately. A CDN edge can fail for one region while the origin looks fine.

We pull a week of responses by template and chart codes and times against deploy dates. The pattern shows which fix comes first.

Media is the part of a site crawlers handle worst. A page can rank while its pictures and clips stay invisible in image and video results.

Images need a plain img element. Google does not index pictures set as CSS backgrounds. Lazy loading is fine with the native loading attribute. A script that waits for a scroll event is a different story, because a crawler never scrolls.

File names and alt text describe the image. A hero called IMG_4031.jpg with an empty alt says nothing. A caption next to it helps. For files served from a CDN on another host, an image sitemap tells Google they belong to your pages.

Video has stricter rules. Google indexes a clip when it is the main content of a watch page. A background loop on a landing page does not qualify, and that is fine. Clips meant for video results each need their own page, a thumbnail crawlers can fetch, and VideoObject markup with name, description, upload date and duration.

Players cause most failures. An embed that loads only after a click gives Google nothing to process. So does a stream behind a signed URL that expires. Search Console's Video indexing report names the reason per page, for example no video detected or video outside the viewport.

Say a studio portfolio shows twenty reels on one page. None of them has a watch page. The fix is structural: one page per reel, the player near the top, the reel described in plain text.

Image addresses should stay stable. A CDN that rewrites file URLs with a new hash on every deploy resets whatever Google knew about each file. Keep the path fixed and version through cache headers.

Text around a clip matters as much as the markup. A transcript in the page's HTML gives Google words to match against queries. A video with only a soundtrack and a title has almost none. For pages that carry several clips, a video sitemap lists each one with its own thumbnail and description.

What we hand over is a list of every template that carries media. For each: whether its images can be indexed, whether its video pages qualify, and the markup it is missing.