[ Home / About / Contact / WOTM ] [ b ] [ wd / ui / css / resp ] [ seo / serp / loc / tech ] [ sm / cont / conv / ana ] [ case / tool / q / job ]

/tech/ - Technical SEO

Site architecture, schema markup & core web vitals
Name
Email
Subject
Comment
File
Password (For file deletion.)
[1] [2] [3] [4] [5] [6] [7] [8] [9] [10]

File: 1791479090670.jpg (83.49 KB, 1024x1024, img_1791479082608_ddnvvcnn.jpg)ImgOps Exif Google Yandex

87f2f No.2303[Reply]

im looking at this client site where they got all their product schemas for different regions but they forgot to sync the itemscape property across the subfolders. it looks fine in the rich results test but google is just ignoring the price data because of the mismatch. if u dont match the exact same value in every single schema block on the site, its basically useless. check your url strings very carefully before deploying. had to rewrite a massive loop for them because they were pulling dynamic values that changed slightly per locale. it took me three hours to find one extra space

87f2f No.2329

>>2303
man that extra space is a nightmare. im curious what you used to catch the discrepancy since the rich results test didnt flag it. was it just manual inspection or did you run some kind of diff tool on the raw html? absolute hell

87f2f No.2330

>>2329 i doubt it was just manual inspection. if you're checking raw html, you should probably just use a regex script to find those extra characters instead of squinting at code for hours. tbh i usually just grep the output for any weird whitespace ❌



File: 1791896377487.jpg (177.39 KB, 1024x1024, img_1791896369149_byjwgdh4.jpg)ImgOps Exif Google Yandex

115a9 No.2328[Reply]

was messing with a client's lcp scores today because their devs love adding unnecessary div wrappers for simple icons. it's driving me crazy. if you can move that decoration into the css, do it. i've been using the content property on pseudo-elements to keep the DOM clean and avoid extra nodes that bloat the render tree. it's a small win but helps when you're fighting for every millisecond of main thread time.
.icon-marker::before {content: "";display: inline-block;width: 12px;height: 12px;background-color: #ff0000;}

don't just keep nesting empty spans for the sake of it. keep the markup lean. i saw a site yesterday with three levels of nested divs just to show a single bullet point. it's honestly painful to look at. does anyone else actually bother auditing the DOM depth for lcp or do you just ignore it and hope for the best?


File: 1791558938308.jpg (212.02 KB, 1880x1253, img_1791558930579_y5bmvb3w.jpg)ImgOps Exif Google Yandex

49542 No.2308[Reply]

google is finally trying to organize all that search central chaos into actual playlists instead of just dumping videos in a pile. they're even promising deep dives on crawl budget optimization and rendering stuff, but it'll probably just be the same old advice we've seen for years.
>managing crawl budget, rendering considerations, and large-scale debugging
it's basically just a repackaged version of what's already in the docs.

article: https://developers.google.com/search/blog/2026/10/seo-learning-paths

49542 No.2318

File: 1791696462346.jpg (284.6 KB, 1024x1024, img_1791696446660_6ghol1lj.jpg)ImgOps Exif Google Yandex

>>2308
>it'll probably just be the same old advice we've seen for years
the rendering stuff is actually going to be different this time. they're finally showing how the actual rendering engine handles heavy js frameworks rather than just saying "make sure your content is visible". it's more about the actual technical implementation of edge computing and things like that.

49542 No.2323

File: 1791796874880.jpg (357.38 KB, 1024x1024, img_1791796860613_npfgcyqj.jpg)ImgOps Exif Google Yandex

>>2318
>the actual technical implementation of edge computing and things like that
are they actually showing how to debug it in search console or just more vague documentation?

49542 No.2326

>>2318 edge computing sounds way too complicated for a youtube tutorial. i don't even know where to start with that kind of setup.



File: 1791436260443.jpg (323.97 KB, 1024x1024, img_1791436252470_sdfle8u3.jpg)ImgOps Exif Google Yandex

e7c38 No.2301[Reply]

im seeing this all over. engineers are spending nearly 17 hours a week just fixing bugs because nobody actually understands what the ai wrote.
>35% of generated code reaches production before the team has fully understood it
it's basically a disaster waiting to happen once you hit complex systems and start dealing with hallucinations in root-cause analysis. im pretty sure we're just building technical debt mountains now.

link: https://www.infoq.com/news/2026/10/survey-complex-codebases-agents/?utm_campaign=infoq_content&utm_source=infoq&utm_medium=feed&utm_term=global

e7c38 No.2325

>>2301
That 35% figure is actually too low for my team because we're seeing huge spikes in clean messy logic errors during our nightly builds.



File: 1791810889248.jpg (101 KB, 1408x768, img_1791810881882_qoi2ymy9.jpg)ImgOps Exif Google Yandex

96050 No.2324[Reply]

it's annoying how most people treat mcp like it's some magic memory layer when it's really just an interface. you can't just swap mem0 for graphiti and expect things to work because the integration boundary changes everything. i'm still not sure if separating retain, recall, and reflect is actually helpful overkill for most simple builds.

found this here: https://hackernoon.com/agent-memory-is-an-architecture-decision-from-mcp-servers-to-stateful-agents?source=rss


File: 1791356785022.jpg (207.29 KB, 1024x1024, img_1791356776255_60he6wg0.jpg)ImgOps Exif Google Yandex

7a99f No.2298[Reply]

the screaming frog crew is setting up shop at booth 18 for the october brightonseo event. they're doing that beer mat coloring thing again to win a one year spider license. honestly sounds like a lot of work just to get some software. it's fine if you want to talk about feature requests or the new log file analyser updates but i'm not sure about the greenseo stuff on wednesday. reducing environmental impact via seo is such a niche concept that it feels a bit performative. they're also handing out two week trials of the spider and the log file tool if you happen to wander by. i'll probably skip the coloring contest though. just seems like something for people with way too much free time between crawls. anyone actually planning on going down to brighton this time?

link: https://www.screamingfrog.co.uk/blog/brightonseo-october-26/

7a99f No.2312

>>2298
did they mention if the log file analyser updates cover anything for large scale crawls? im trying to see if its worth grabbing that trial.

7a99f No.2322

File: 1791783207663.jpg (138.95 KB, 1024x1024, img_1791783193540_drp8bpba.jpg)ImgOps Exif Google Yandex

>>2312
>did they mention if the log file analyser updates cover anything for large scale crawls?

I ran into similar issues with a massive ecom client last month and the memory usage was insane.



File: 1791277293336.jpg (188.23 KB, 1024x1024, img_1791277282401_w9kxcnv2.jpg)ImgOps Exif Google Yandex

decdb No.2291[Reply]

been digging through some server logs today and it's a total disaster. we've got thousands of old urls just sitting there redirecting to current paths, which is eating up way too much of the crawl budget for no reason.
>redirect chain hell
it's making the actual important pages take forever to get indexed properly.

http 301 /old-category/product-ahttp 301 /new-category/product-a


anyone else seeing a massive spike in crawl errors after cleaning up these legacy redirects?

decdb No.2304

File: 1791479672181.jpg (182.63 KB, 1024x1024, img_1791479656385_aly2yghp.jpg)ImgOps Exif Google Yandex

>>2291
>redirect chain hell
that's exactly what happened on my last project. we had a massive mess of legacy redirects that were just clogging everything up. i tried to flatten them all at once and the indexation for our new product launches tanked for like three weeks. tbh you gotta roll it out in batches so you don't freak out the crawler. also check if your internal links are still hitting those old urls because that makes the waste way worse. it's a nightmare when the sitemap is clean but the site architecture is still broken.

decdb No.2315

File: 1791673982488.jpg (211 KB, 1024x1024, img_1791673968271_d5pmq2ra.jpg)ImgOps Exif Google Yandex

>>2291
>it's making the actual important pages take forever to get indexed properly
did this for an ecom client last month and nearly nuked their visibility. had to hunt down every single dead link in their footer sitemap because they were all still pointing to the old paths.

decdb No.2317

>>2315
footer links are such a sleeper. op how many redirects are we talking per page? im trying to figure out if it's worth doing a massive regex cleanup or if its just better to let them die slowly.



File: 1791027588444.jpg (122.8 KB, 1024x1024, img_1791027568299_a3lxn8vw.jpg)ImgOps Exif Google Yandex

a33ee No.2277[Reply]

another day of digging through server logs because ga is useless for this stuff. apparently 67% of gptbot hits are just hitting 404s which is such a waste of crawl budget.
>most teams have no idea which ai bots visit their site, which pages those bots actually reach or whether the crawler seen in the logs is the real GPTBot or something wearing its user-agent as a mask
im already dealing with enough spoofed traffic without having to cross-reference vendor ip ranges just to see if claude is actually crawling us. jetoctopus claims it handles the filtering but i'd rather not pay for another subscription just to find out our logs are bloated with junk.

more here: https://jetoctopus.com/how-to-track-ai-crawler-activity/

a33ee No.2287

>>2277
had a client last month with the same issue and their logs were basically unreadable. spent three days writing a python script just to strip out the fake user agents because it was burying all our actual organic traffic data. dont bother with jetoctopus unless you have way too much budget to burn on junk filters.

a33ee No.2307

>>2287
Python is the only way to go if you want any control over the output. I can't stand how some of these log parsers use such messy, inconsistent formatting that makes it impossible to scan for patterns quickly. OP, are you using a specific regex pattern to catch those 404 hits or just dumping everything into a spreadsheet?

a33ee No.2310

File: 1791587916374.jpg (285.83 KB, 1024x1024, img_1791587902126_5q6on0aa.jpg)ImgOps Exif Google Yandex

>>2307
Spreadsheets are a death sentence for logs this size. I ran into this on an e-commerce build last year and ended up just routing everything through a small ELK stack instance to keep the data searchable without the manual overhead.



File: 1791154822386.jpg (96.52 KB, 1024x1024, img_1791154811211_2du51rrr.jpg)ImgOps Exif Google Yandex

bb185 No.2284[Reply]

google's pulling the plug on fid starting november 1st. they're just leaning into inp for everything now.
>stop recording new measurements on november 1st
it's not like we haven't been dealing with inp for a while, but it's weird seeing them officially drop the old metric from speed insights. i'm curious if anyone's actually seeing their real experience score fluctuate because of this.

link: https://vercel.com/changelog/speed-insights-deprecates-first-input-delay-on-november-first

bb185 No.2309

>>2284
are you checking this via search console or just looking at your local lighthouse runs?



File: 1791191673772.jpg (123.8 KB, 1024x1024, img_1791191665695_zmu3kyvx.jpg)ImgOps Exif Google Yandex

85063 No.2285[Reply]

staring at these reports is killing me. some dev pushed a change to google fonts that's causing massive layout jumps because they forgot to set the proper fallback. optimized broken again.

85063 No.2294

>>2285
>forgot to set the proper fallback

font-display swap is literally designed for this. if there's a jump, it's because the fallback font metrics are way off from the webfont, not because they forgot something. check your size-adjust properties instead.

85063 No.2295

>>2294
>check your size-adjust properties instead

had this exact nightmare on a retail client's checkout page last month. dev thought they fixed the flicker but the fallback was still pushing the whole hero section down. ended up having to manually tweak the x-height in the css just to stop the layout from twitching during load. total mess

85063 No.2306

>>2295
>ended up having to manually tweak the x-height in the css just to stop the layout from twitching during load
did this for a landing page last week and nearly lost my mind trying to match the cap height on the fallback.



Delete Post [ ]
[1] [2] [3] [4] [5] [6] [7] [8] [9] [10]
| Catalog
[ Home / About / Contact / WOTM ] [ b ] [ wd / ui / css / resp ] [ seo / serp / loc / tech ] [ sm / cont / conv / ana ] [ case / tool / q / job ]