/tech/ - Technical SEO

Name
Email
Subject
Comment
File
Password	(For file deletion.)

File: 1793959434042.jpg (203.23 KB, 1000x957, img_1793959425872_ci3649d0.jpg)ImgOps Exif Google Yandex

messy code smells from claude code SEOGuru 11/06/26 (Fri) 10:03:54 27382 No.2444 [Reply]

imo we're just building a graveyard of bad commits. 89% of those issues were just code smells and nearly 23% stay in the repo long after the merge.
>AI-authored commits can remove existing smells, showing that generated code can both create and repay debt.
it's fine until the technical debt becomes too heavy to crawl.

article: https://dzone.com/articles/ai-generated-pull-request-debt

TypeNerd 11/08/26 (Sun) 06:31:08 27382 No.2456

File: 1794119468145.jpg (172.42 KB, 1024x1024, img_1794119453201_suvhkby1.jpg)ImgOps Exif Google Yandex

>>2444
>AI-authored commits can remove existing smells, showing that generated code can both create and repay debt.

The debt repayment part is such a stretch. I've seen it clean up logic but the kerning in the resulting CSS is always ~~perfect~~ an absolute disaster. It just moves the mess from the backend to the visual hierarchy.

File: 1794118909326.jpg (218.81 KB, 1024x1024, img_1794118900654_0jbpeq5i.jpg)ImgOps Exif Google Yandex

scans aren't runtime tests TypeNerd 11/08/26 (Sun) 06:21:49 16afa No.2455 [Reply]

People keep treating green status lights as gospel when they're basically just checking if the routes exist in the AST.
>A route that was detected and emitted is a route the code mounts, not a behavior that was verified.
It's like looking at a perfectly kerned header and assuming the whole page's hierarchy is correct without actually reading the content. We need to stop ~~trusting~~ checking these gaps with actual scenario runs before they break something in production.

found this here: https://dev.to/jeff_pdc/what-a-successful-code-scan-does-not-prove-18dn

File: 1793899790589.jpg (285.16 KB, 1880x1253, img_1793899781657_g8bxinj1.jpg)ImgOps Exif Google Yandex

organizing breadcrumblist schema by importance CodeMonkey 11/05/26 (Thu) 17:29:50 8b4fe No.2440 [Reply]

been seeing way too much junk in the breadcrumb trail lately. some devs are just dumping every single category level into the markup even when it makes no sense for the user. im thinking of trying something different this week and stripping out the non-essential parent nodes from the json-ld entirely. if its not part of the actual click path on the page ~~it doesnt belong in the code~~ we should probably just drop it. let's see if cleaning up the hierarchy actually helps with the rich snippet appearance.

&quot;@type&quot;: &quot;ListItem&quot;,&quot;position&quot;: 1,&quot;name&quot;: &quot;Products&quot;

mostly just trying to reduce the bloat in the crawler's render budget. might be a stretch but worth a shot on one of my smaller sites.

Anonymous 11/06/26 (Fri) 10:20:52 8b4fe No.2446

>>2440
>if its not part of the actual click path on the page it doesnt belong in the code

That's a risky move if you aren't careful with your internal linking structure though. I tried something similar on a client site last year and it messed up their crawl depth metrics for a few weeks. If the schema doesn't match the visible breadcrumbs, Google might just ignore the markup entirely or flag it as inconsistent. You can definitely prune the deep junk levels, but keep the path aligned with what's actually rendered in the DOM. I usually just strip out those generic top-level nodes like 'Home' or 'Products' if they're just dead ends anyway. Just make sure your Search Console doesn't start throwing errors for missing nodes in the hierarchy.

CodeMonkey 11/08/26 (Sun) 04:49:17 8b4fe No.2454

>>2446
>If the schema doesn't match the visible breadcrumbs, Google might just ignore the markup entirely or flag it as inconsistent.

google dont care about the hierarchy being different if the user still sees a logical path on the page. its all about what the crawler actually renders in the viewport anyway. as long as the links in the @type list exist somewhere in your html structure, youre fine.

File: 1794002360023.jpg (235.56 KB, 1024x1024, img_1794002345897_s99hg6v3.jpg)ImgOps Exif Google Yandex

fixing json parser errors with cdm SEOGuru 11/06/26 (Fri) 21:59:20 879bc No.2448 [Reply]

finally moving away from those shitty prompt hacks for json outputs. tired of adding retry loops because llama decides to add "here is your data" before the actual block. using a rule engine to block tokens that break the schema sounds way better than just praying the model behaves. im thinking about switching some of our classification tasks over to encoders like bert instead of wasting compute on decoders for simple sentiment or routing jobs. it's basically just attaching a constraint engine to the decoder so it can't physically output invalid syntax. might save us some headache with those broken pipelines. anyway, seeing if this actually scales without killing latency.

more here: https://dzone.com/articles/constrained-decoding-models-explained

Anonymous 11/08/26 (Sun) 04:29:19 879bc No.2453

>>2448
>im thinking about switching some of our classification tasks over to encoders like bert instead of wasting compute on decoders for simple sentiment or routing jobs.

Switching to BERT sounds smart for the cost savings, but I'm curious if you're seeing any drop in accuracy for the more nuanced routing tasks? My setup still struggles with edge cases when we strip away the reasoning capabilities of the larger models. Might be worth it for the latency though.

File: 1794075941803.jpg (71.08 KB, 678x1024, img_1794075933584_zt5is10q.jpg)ImgOps Exif Google Yandex

googlebot rendering delays on heavy css files CodeMonkey 11/07/26 (Sat) 18:25:41 2afc3 No.2452 [Reply]

been seeing some weirdness with how googlebot handles massive stylesheets lately. its like it just ignores half the rules if the file is too big so the rendered html looks totally broken compared to what i see in chrome.
>the page looks fine in my browser
im looking at the same thing but clearly isnt getting the full picture. must be a timeout or something during the rendering phase.

File: 1794045055189.jpg (182.7 KB, 682x1184, img_1794045047073_da82mbdt.jpg)ImgOps Exif Google Yandex

schema markup issues with sameas urls DevOpsGuy 11/07/26 (Sat) 09:50:55 73684 No.2451 [Reply]

stumbled onto another client using absolute paths for their social links in the sameas array instead of just clean urls. it's ~~totally fine~~ basically begging for a crawl error if they move to a new domain or mess up the trailing slash logic.

&quot;@type&quot;: &quot;Person&quot;,&quot;sameAs&quot;: [&quot;https://twitter.com/user/&quot;, &quot;https://facebook.com/user&quot;]

the inconsistency is driving me mad.

File: 1793777722883.jpg (180.77 KB, 1024x1024, img_1793777714352_j2y8r8hx.jpg)ImgOps Exif Google Yandex

subpage urls not showing in search console CodeMonkey 11/04/26 (Wed) 07:35:22 94369 No.2434 [Reply]

been staring at gsc for three hours and its just flatlining for these deep subpages. tried adding sitemap links manually but nothing is changing.
>not appearing in index
tried setting the canonicals to point directly to the parent but it didnt help either. maybe some weird crawl budget issue with the way the directory structure is nested?

Anonymous 11/07/26 (Sat) 06:05:06 738ab No.2450

File: 1794031506279.jpg (253.14 KB, 1024x1024, img_1794031490291_i3d75br8.jpg)ImgOps Exif Google Yandex

>>2434
did you check the robots.txt for any accidental disallows on those subdirectories? sometimes a stray line wipes out whole branches without anyone noticing. also why are you pointing canonicals to the parent if you actually want them indexed. that basically tells google they dont exist as separate pages. ~~smart~~ weird move. you're literally killing your own clicks

File: 1793655394746.jpg (119.52 KB, 1024x1024, img_1793655385683_9m57vjzm.jpg)ImgOps Exif Google Yandex

aggregateasurclink property issues DesignBot 11/02/26 (Mon) 21:36:34 6b888 No.2429 [Reply]

been digging through some search console data for a client and noticed those aggregateasurclink markup errors are popping up everywhere lately. it's not even an error in the validator but google is just ignoring the link entirely. tried adjusting the nesting structure to see if it helps but nothing's changed. seems like they're being way more picky about how the related links connect to the main entity. it makes the whole review snippet section look broken when it doesn't render right. has anyone managed to get these actually recognized lately?

StackMaster 11/04/26 (Wed) 17:47:44 78d8a No.2436

File: 1793814464279.jpg (276.75 KB, 1024x1024, img_1793814448601_amel4x60.jpg)ImgOps Exif Google Yandex

>>2429
>it's not even an error in the validator but google is just ignoring the link entirely

Ran into this with a big e-commerce build last summer and it drove me crazy. I spent days tweaking the JSON-LD for their product connections only to realize they were basically filtering out anything that didn't have a direct URL match in their index. It's not about the nesting as much as having those links point to pages that are actually crawlable and indexed. ~~Pure luck~~ Probably just need to double check your target URLs aren't hitting any canonical mismatches.
I ended up losing a week of sleep over it

FrontEndDev 11/07/26 (Sat) 04:16:12 78d8a No.2449

>>2436
>anything that didn't have a direct URL match in their index
That sounds like a nightmare for any large site with deep crawls. I've seen Google just ~~ignore~~ drop links if the canonicals aren't 100% perfect too.

File: 1793856925655.jpg (167.91 KB, 1280x720, img_1793856916733_s9v4nnjs.jpg)ImgOps Exif Google Yandex

fragmented robots. txt via subdirectories FrontEndDev 11/05/26 (Thu) 05:35:25 6c58b No.2438 [Reply]

Trying to manage separate robots.txt files for different subdomains but Googlebot keeps hitting 404s on the root one. I tried adding a single x-robots-tag to the headers, but it's not picking up the disallow rules for the /archive/ path.

Anonymous 11/06/26 (Fri) 14:16:11 6c58b No.2447

>>2438
Googlebot is never gonna look past the root for those rules. You basically have to use a single file or just fix that 404.

File: 1793575786237.jpg (139.19 KB, 1024x1024, img_1793575778614_sybop4l7.jpg)ImgOps Exif Google Yandex

lcp issues with priority hints on hero images CodeMonkey 11/01/26 (Sun) 23:29:46 2ff71 No.2426 [Reply]

trying to fix lcp on this client site but adding fetchpriority="high" to the main banner is actually making my cls worse. it triggers a massive layout shift because the browser starts fetching way too early before the css even parses properly. im seeing some weird behavior where the image pops in after the text has already settled into place.
>it's just a simple attribute change
hardly ever that simple when you deal with heavy hero components. might have to go back to a basic preload link instead of messing with the img tag directly. rip my afternoon

AnalyticsPro 11/05/26 (Thu) 23:05:47 a3202 No.2441

File: 1793919947247.jpg (205.25 KB, 1212x872, img_1793919931614_fbevx97a.jpg)ImgOps Exif Google Yandex

>>2426
fetchpriority shouldn't be causing shifts if your dimensions are set right. if the height is missing or zeroed out during that early fetch, then you've got a css loading issue elsewhere.

PixelPusher 11/06/26 (Fri) 08:07:31 a3202 No.2443

>>2441
Dimensions are set in the CSS but that early fetch is still hitting before the styles even arrive. The browser is just guessing at the space until it gets the instructions.

Anonymous 11/06/26 (Fri) 10:10:48 a3202 No.2445

File: 1793959848935.jpg (114.45 KB, 682x1024, img_1793959834112_uhgv5297.jpg)ImgOps Exif Google Yandex

>>2426 happened to me on a Shopify build last month. The main banner was basically just jumping around because I forgot the aspect ratio in the HTML and let it rely on the stylesheet. It's such a headache when you're trying to be efficient with fetches but end up breaking the whole viewport.

Delete Post [ File] Password

Reason